 All right, welcome everybody to this Thursday online workshop, wherever you are in the world. As you are joining, please do feel free to get your local WordPress install up and running if you want to do the testing along with us today. Today is going to be a, I would say, a lot simpler and a lot easier session maybe than what I normally do. We're not going to be massive amounts of coding today. We're going to be using tools that are easily available. And from the repository and just keeping things very, very straightforward today. So while you are joining, please do consider letting us know in the chat what part of the world you're joining us from, maybe what time it is where you are. I'm always interested to know what time folks are joining us. And then maybe something interesting about your country or your world that you live in. While you're doing that, my name is Jonathan, and I am updating my slides as I introduce myself. My name is Jonathan. I am from Cape Town in South Africa. I'm an ex developer now to what's known as a developer educator. And so that just means I do these kinds of online teaching sessions, showing folks how to do things, preparing tutorials, creating lesson plans and all that kind of thing for learn WordPress and courses as well. And I'm a full time sponsor contributor at Automatic. So what that means is that Automatic pays me to do this work full time to work with the training team in the open source WordPress project. And and help folks learn how to do all these things. So I always say to folks that if you have questions about how to do things with WordPress to how to develop with WordPress. Don't feel like you can't reach out to me because it is literally my job to help you find answers that is literally what I'm paid to do and it's one of the things that I love about my work. Good morning from from Southern California it's raining. As we are having severe drought yes rain is very welcome all over the world Cape Town is also dealing with drop at the moment we you may know a couple of years ago about six seven years ago Cape Town was having day zero warnings about running out of water and all that kind of thing so we're also very happy about rain that we had recently. And you have a large cup of coffee that's excellent I I've stopped drinking coffee after 2pm 3pm, because I found that it was keeping me awake at night. This is either an age thing or just my my current cycle but I've stopped drinking coffees I just have water today so I will just be taking waters as we go along. Marcus from Washington also 6am in the morning. And it's currently snowing that's amazing. I have never, I have never experienced what I would refer to as proper snow. We do have snow in Cape Town in the winter in the middle of winter, but it's only when it's extremely cold in the very high mountainous areas, which is about an hour and a half drive away from where I stay. And it's a very icy snow. So it's not the powder that that I that I've seen in the movies. If you if you were to make a snowball with the snow and throw it at somebody you might kill them by mistake so it's not snow that you want to mess with. And funny story the last time we went up to see the snow was probably 2018 or 2019. So that would have been safe. Four years ago which makes sense my youngest would have been about three three and a half. And he had managed to fall over in the snow and get a bunch of snow in his boots. And he's any socks got wet. And without thinking without realizing this he took his socks off and put his boots back on but they were still snow inside of his boots and as I'm sure those of you who understand cold temperatures and icy snow that meant that one of his toes started getting a bit of frostbite. He picked it up in time but his, his toenail was black for a few weeks after that. So fortunately nothing, nothing bad happened there. We have Drake from Pennsylvania also rain. 9am EST. So bum from. Please forgive me if I pronounce this incorrectly Chen Chen Dera. Chen. Thank you. Thank you. 730pm there so welcome folks that are joining after what I call work hours. I really appreciate folks who joined me first thing in the morning, you know, five, six a.m. or who joined me to run about this time I, I would not be able to join a 730pm workshop. Purely because that's around supper time and getting ready for bedtime with the boys and making sure everybody's done their homework and brush their teeth and shower to those things so I appreciate it when folks join me outside of comfortable time so welcome everybody. Awesome. So today we are going to be learning how to test WordPress. For those of you who don't know and we'll cover this in a short bit, the new WordPress version. Adrian says yes I remember those days of shipping he gets to bed. Yes. I look forward to the days when I can remember it and not have to look through it. So for those who don't know the new WordPress 6.2 release is due sometime towards the end of March. And it's it's always helpful to the WordPress core team into the WordPress developers to help test WordPress. And so today we're going to be looking at at least the process that I follow for testing WordPress, and hopefully be sharing some tips and tricks, sharing some information around where to to log issues if you do find them. And how to go about doing all of these things. So hopefully this is something that is useful to everybody. I'm probably going to look at redoing this workshop every time there's a release coming up about a month before the release is due. Because it just means I don't have to prepare for that workshop that could just redo the same thing over and over again and just change the 6.2 to whatever the next number is. So if you if you do miss this one we will do it again in the future. Okay, as always a couple of announcements before I start. First of all, again, welcome everybody. And also thank you to Joshua who is co hosting with me today this is the second time co hosting so it's always nice to have a recurring co host. So thank you Joshua for for doing that. We are as always presenting in focus mode which means I can see your screens or your video feeds, but you can't see each other and this is just to prevent any kind of zoom bombing that unfortunately does still happen. It hasn't happened in a while. But but it's something we want to just stay away from. Maybe one day we'll get around to some kind of service where we don't have to worry about this but for now we just want to protect our, our community from from dodgy people. But if you would like to please feel free to enable your video if you would like me to see you or Joshua to see you. You're welcome to also leave it off I don't mind. It's entirely up to you. Then please let me know if you can't see my screen right now so what you should be seeing is this announcements slide the slide is titled announcements. If you can't see it or if at any point in the session. If you or anybody you you see in the chat can't see my screen let me know. It's specifically an issue on Linux operating systems, but it could crop up on Mac OS or Windows so do let me know if you can't see my shared screen. And then finally as always you are welcome to ask questions you're welcome to post your questions in the chat or new to ask questions. I do pause periodically to look out for questions. And if I miss anything Joshua will also help me find those so you're welcome to ask questions as we go along. All right. Last reminder to get your local install ready if you want to work along with me. As always, if I'm going too fast please do let me know somebody was kind enough to email me last week after the MA. And let me know that I was going very fast and I think the problem there was that I wasn't. It wasn't a prepared workshop I was just answering questions off the cuff. I'd also had probably one too many coffees that day so that didn't help. But if I'm going too fast if the if the captioning is not keeping up with my my pace of speed. Please do let me know you're welcome to just in the chat just go slow down. I won't take offense. I know I talk fast it is a it is a failing of mine that I have to remind myself of regularly. So I won't take offense if you just in the chat you can even caps caps lock on slow down charted me I don't mind. We will be posting the session to WordPress TV afterwards as always probably during the course of the day tomorrow or going well. And if you're looking for more WordPress focus content please do visit learned on WordPress.org that is the platform that myself and all the other folks in the training team work on. If you have any follow up questions or feedback from the session. If you're comfortable with using GitHub. There is a there is a GitHub issue for this workshop if you're watching this recording afterwards, and you would like to leave feedback or questions you're welcome to use this GitHub issue. The other option that you do have and this is something that I haven't added to my slides just yet but I will probably start doing it from next week is to use this a m a dot Jonathan Boston dot com URL that I've set up. Let me just take out all this login nonsense. If you joined me last week I was I was showing you how I created all of this. I'll paste this in the chat but this is basically a form on a sub domain of my top level domain where you can just post the question to me. And you're welcome to use this form to post any questions so please feel free to use that if you're not comfortable with using the GitHub issue. Okay. Today's outcomes as I mentioned earlier we're going to be looking at how we can test the new WordPress release. We're going to start by configuring our local testing environment we're going to talk a little bit about how we can do that. Then we're going to I'm going to show you how to configure WordPress debugging and why I recommend doing that while testing. Then we're going to talk about testing themes and plugins, either your own themes and plugins or if you want to test other themes and plugins. You work with a team or you use a plugin regularly and you want to see if it's ready for the next version of WordPress. And then we're going to talk a little bit about testing some new features coming out and how to find information around these features where to go, what to pick and that kind of thing. So those are the four main objectives today or outcomes today are actual objectives that we're going to follow to achieve these outcomes. I'm going to introduce you to something called the WordPress based beta tester plugin. There are a number of ways to set up your WordPress install to run on the latest version. The beta tester plugin is just the easiest way to do it. We will chat about the other options I won't necessarily show you them but we can chat about them. But the beta tester plugin is about the easiest. We're actually going to go through and configure the plugin to install the latest beta or what's known as a release candidate. Then we'll physically update our WordPress install. Then what I'm going to do is I'm going to test out to that AMA plugin that I showed you with at least the AMA form. I'm going to test that out on my WordPress install. So I'm going to find the code, the development code. You're welcome to download it yourself. And then we can test it out and we can see if it has any bugs or any breaks or any issues. Then I'm going to show you, we're going to test out one or two developer focused features. I'll show you how to find those and what we can look for. Then I'm going to also discuss where to ask questions and where you can go to find out more information and finally where and how to log bugs. So if you find an issue in a WordPress release, where's the best place to log that issue? We'll talk a little bit about GitHub versus track and what those two things are, if you've never seen them before. And we'll talk about how you can log issues in one or the other. So those are our objectives for today. All right, I'm going to grab a sip of water. If anybody has questions about everything that I've just discussed there and our objectives and our learning outcomes, please let me know. Otherwise we will start testing. Okay. So the first thing that I'm going to mention is that WordPress always has a whatever the new version release number. And I'm pasting this in the chat now post on the make that WordPress.org website in the core in the core team. I'm trying to make my, my things are working. There we go. Let's make it 120 125. And it's usually something like this URL here make that WordPress or slash core slash 6.2. So whatever the next version number will be will be 6.3 or whatever it is. It's usually something along those lines. And there is a development cycle post and it talks about who the release team is the release leaders typically Matt unless he's handed that responsibility to somebody else. Then they are release coordinators they are the folks that sort of manage the release, excuse me. And then they are leads for all of the different parts of a WordPress release. So there's the core release editor, sorry, the core part editor part core triage which has to do with testing. Edited triage which has to do with editor testing documentation marketing and communications test design and performance. So those are the main sort of parts of a WordPress release. And you will see that all the people that are listed under those responsibilities are tagged in this conversation. So those are the folks that you can reach out to if you have any questions around any parts of the release. There's usually a release schedule. So it has all the different dates and when things are happening there's a pre planning post. And then usually about roughly two months after that planning post the first beta start coming out. And we are now here we are in this February 21 February 28 time period beta three was released on February the 21st and beta four will be due on February the 28. We usually don't test during a beta period. I usually wait until the release candidates start coming out. So if you don't know what a release candidate is in software development terms, a release candidate means we think this is ready. We've, we've, we've fixed all the bugs we could find internally. We've done as much testing as we can. We now we're at this point where we think this is ready. You will see that there are usually three to four betas but only one to three release candidates. Sometimes there might be a fourth release candidate pushed out. If something gets picked up in any of the RC cycles. But you will notice that in the trying to find a chair quickly. Where is it now. There's a soft string freeze as a hard string freeze. I'm looking for another. What's seeing a chair. Here we go. After release candidate three there is the dry run for the release. And there's a 24 hour code freeze before the dry run. So that usually happens the day before the final release. So I usually start testing a roundabout release candidate one release candidate two because that's getting really, really close to being sort of final. But it's okay to start testing during a beta period. When I was working. So when I say I testing I'm talking about just testing personally on my blog just to help testing WordPress core. When I was working for a company that that was building and maintaining a popular WordPress plugin, I would actually start testing from beta one. So if there were any inconsistencies or incompatibilities between what was coming in my plugin, I wanted to be able to figure out early. Is there something I need to fix or is this a core problem so depending on your use case, depending on how you're testing my determine when you start testing. So just wanted to mention that before we continue. Okay, so that's the testing cycle. And that's where you can find that information. While we're on this page, if you've never been there before, the make dot WordPress dot org website is the site that manages and controls all of what we call the make teams. So the make teams are all the volunteer teams that contribute to making WordPress hence the term the make teams. And so the core team is the team that manages the core WordPress software, and then you got all of these other teams. And then further down this list here, you've got the training team, which is the team that I contribute to. And the training team works on training and learn WordPress and those things. So if you are wanting to contribute to WordPress and you don't want to contribute to testing, for example, core stuff. Have a look at some of these other teams and see where your skills are and see where you can start. I personally, and this is not related to testing. I'm just mentioning this. I was a developer when I started contributing to WordPress, and I started contributing to the documentation team, because the last thing that I wanted to do when I got home from work is do more code. But documentation was something that I felt like I could do in my spare time so I helped with some of the at that stage when I joined. They were migrating from what's known as the what was known as the codex it's still around but over to the new developer hub at developer dot WordPress.org. And all I did at the time was help copy pages from the codex to dev app. That's all I did. So I went into an old post, copied out all the content, opened up the new post in dev hub, pasted it, updated the fact that I'd done that in a spreadsheet and moved on to the next one. That's all I did. And that was fun because it was simple. It was easy and I was contributing to WordPress. So I do recommend if you're looking for somewhere to contribute, you know, even if you only have like one hour a week or one hour a month. Have a look through all the different teams get to know them and find one where you can possibly think about giving back. Okay, so that's that's make WordPress and that's how you can find the core team. And as I say that that that release blog is always available. You'll also notice I clicked through to the core team there's usually a, a pinned post at the top of the core teams blog, and it usually relates to the latest release so this one is the bug scrub schedule. It was created on January the 18th and they're talking about all the different bug scrubs. So what a bug scrub is, is all of the bugs that folks like us who are going to do testing today have logged get scrubbed they get cleaned out and seen whether this is something we're going to fix now where they're going to punt it to a following release and all those kind of things. So it's just interesting to know where these things are and how to find. Okay. Let me check my. So let's get on to the first one that we're going to do which is installing the WordPress beta tester plugin. Now, usually, and I was I was mentioning this to Joshua before we started. Usually when I test WordPress in my personal capacity, I install the beta tester plugin on my personal blog. And when beta one comes out I update my blog to be on bait whatever beta one is. That's okay because it's my blog. And if anything breaks or goes wrong it's not causing anybody pain it's not going to cost anybody money. If my blog doesn't work for one day it doesn't really affect me too much somebody might might message me which has happened before on Twitter or on various social media platforms or via email and say hey this link is broken or that page is broken or whatever. And that's part of the reason why I do it because then I can see. I let sort of the universe discovered my blog and then if they find bugs they can let me know and if it's a WordPress blog I can log it. So that's the one reason I do it that way. If you are testing this for your own purposes. I don't recommend testing that on any production sites any client sites anywhere that's going to cost anybody money because beta software is beta software. It can have bugs. So what I usually do is I will make a copy of whatever client sites I want to test it on my local environment, and then I will do the testing there. For today's purposes I'm just going to use my normal learn press site. And I'm cheating a little bit here because my plan, my personal work plan if you will is to always be on the latest release. And so I would have done this step what I'm doing now anyway for work so now I'm going to just share it with you. But basically it's a case of going into your plugins list. I don't think I have it installed anymore. I think I installed it a while back in your plugins list just clicking on add new. And then you can just search for WordPress beta tester in the search bar. You can also obviously download the plugin from the repository and install the zip file that way. You know, there are multiple ways to do it but the sort of easiest way to do it is just to install WordPress beta tester in the add plugin screen. You'll see it's the first result comes up because I don't think anybody else has developed a beta tester plugin because this one just works really, really well. And you can just from your plugins screen you can just click install now and it will install the plugin. It doesn't do anything else but install the plugin when the plugin is installed and activated. It requires you to actually go through the process of installing the plugin and activating it then telling it which version of WordPress you want to have up and running. So you can leave it installed in your site if you would like to. Usually what I do on my personal blog is I leave it installed until the release comes out. Once the release comes out I disable the beta tester plugin and allow WordPress to do its normal auto update. And it then updates to the latest release and I leave the plugin uninstalled on my site. There's a little bit of extra overhead in doing so but it's not the end of the world. And then once we get back into beta testing then I just enable the plugin and re-enable the settings that I'm about to show you. So there's multiple different ways you can do it. If anybody is following me along right now and you're still busy waiting to install your plugin on your site please do let me know. If you are, if you have installed it and you're active and you're ready to go give me a thumbs up. Or if you're just watching along and you're ready to move on give me a thumbs up in the chat while I grab a sip of water. Again if there are any questions let me know. This shirt looks good to go. Nobody else seems to be asking me to wait so that's good. So once the plugin is installed if you go into your tools menu in your dashboard you will see there is a beta testing option under tools. If you click on that option it takes you to the beta tester screen. And you will notice that it does say once you have switched your website to one of these beta versions of software. It will not always be possible to downgrace as the as the database structure may be updated during the development of a major release. And that's another reason not to do this on a very important site. Personal blog that's your choice on my site. I'm not fazed. I don't have any weird database things happening so if a database upgrade breaks things it's fine. My my web host backs up my site every day anyway. And I don't tend to blog too much during the beta period so if I do lose a blog post it's not the end of the world. I'm not aware of that. And you'll see in the core settings it says you're currently your site is set to update to version 6.1.2 alpha 5543 yours might be slightly different. Mine is saying that because if you look down at the bottom here my current version is version where sorry version 6.1.1 which is the current release. So it's going to update to whatever alpha is I don't need to worry about 6.1.2 alpha now because I want to test 6.2. So the way we do that is we switch to the bleeding edge option. Now to some folks that don't bleeding edge might sound scary. It's not really that bleeding edge it's it's kind of like yards the new stuff but it's not going to it shouldn't really destroy your site. And then don't take the latest daily updates. Fun fact. Matt Mullenwick the co-founder of WordPress he actually runs his personal blog on the latest daily updates. He mentioned this a few times on his blog on social media. I don't go that route I go for the beta RC route only. So that's only going to give me betas or release candidates for the next version that's coming out. So I switch it to bleeding edge and I switch it to beta RC only. You can also just go release candidate only if you want to and then it'll only be ready when the release candidates come out. For today's purposes because we're only in beta phase we do need to make sure that beta is enabled. So again depending on where you're you're testing will determine that setting and then you just hit save changes. And then at the top of that screen it'll say saved why don't you head on over now and upgrade and I love this because it's a little link that will take you straight to the upgrade page. You click on that. And now WordPress should tell us that we are ready to install 6.2 something so here we are on current versions 6.1.1. And if we scroll down and updated version of WordPress is available. And here it says update to WordPress version 6.2 beta 3 which is exactly the one that we want. So before I go any further. Yes. Drake has a question here. Okay cool cool I see that any reason to run beta tester and the Gutenberg plugins simultaneously. Or should Gutenberg be disabled if beta is used. That's a good question Drake I'll get to that in a second let me just finish what I was saying. Is anybody else who's working along with us not seeing the upgrade to version 6.2 beta screen. If you are let me know in the chat while I answer Drake's question. Okay, so that's a very good question drink. What we need to remember when it comes to WordPress development and Gutenberg development is that Gutenberg development. One of the reasons why Gutenberg is developed separately on GitHub and not part of the core release. Gutenberg wants to be able to just kind of run ahead and start doing new things and trying out new things and testing new things and getting feedback. So when it comes to testing specifically a 6.2 release. I then update to the beta and disable the Gutenberg plugin because I want to see only what's coming out in that release. I might leave the Gutenberg plugin in and disable it, but I won't have it enabled at the same time because then I'm getting additional features that are available in the Gutenberg plugin that might only come out in 6.3 or 6.4. However, if I want to test those things that I will leave it enabled and I would let it run at whatever version it's at. But if I'm specifically wanting to test for the current release cycle. Then I'd leave the Gutenberg plugin disabled because whatever is so the way that the way that they work is when the release cycle is sort of plan. The Gutenberg team editor team they're called they will decide what of Gutenberg at what point will we will we stop and say all of this will be included in the 6.2 release. And then once that is included they will then continue working on other features while they're fixing bugs for the 6.2 release. But if you have the Gutenberg plugin installed an active while you're testing a specific release you're going to get features that might not be included in the release. And you might either a think things are coming and there are not or test things that aren't coming and you might log things that aren't supposed to be there. And I'll explain why that's important when we get to the way to log issues things. There's no reason why you can't have the beta tester installed and the Gutenberg plugin sort that that's perfectly fine I've done that before as well. It really just depends on what your specific testing focuses. If you're wanting to test specifically for the 6.2 release just have the beta tester installed, and that will then include any editor enhancements that are coming for that release and disable the Gutenberg plugin. Okay. Cool. Nobody has also no problem. Nobody seems to have had any problems getting to this point if they are following along so now we're going to do the update. So it's just literally a case of and it's actually that's a good point let's actually check whether Gutenberg is installed an active I don't think it is. No, I don't have it installed on this site. I have it on my on my development site but not on my but this is my live online workshop site if you will. So let's pop back on over to the updates page and let's just hit that update to version 6.2 beta three button. And it should all go fairly smooth. One of the great things about WordPress is that it's got this commitment to backwards compatibility. There is there is a tester, and I've actually been part of the testing process when a new beta comes out. There is a tester out there who has I think back to version three or something. And he tests the upgrade from that version three to whatever the latest version is every time they release a beta or release candidate to check whether the upgrade happened successfully. And if it doesn't then he figures out why any logs issues and they fix it and they make sure that folks and still upgrade that far back. So that is definitely something that is something that WordPress is committed to. Now, usually the upgrades don't take this long. This could just be a problem with my local Wi-Fi right now. I'm going to just quickly have a look at my dev tools and see if there's any reason why, why this should be taken this long. It shouldn't. Oh, there we go. It's done. Okay. There we go. Doesn't normally take this long for me. It could just be a downloading issue. But there we go. I've now got WordPress 6.2 installed. You will notice that usually in the beta period they start putting together the about page. But a lot of the information on the about page is not related to 6.2 itself. For example, whatever that current version is. So this is actually probably, yes, this is probably 6.1 stuff because 2023 was released when 6.1 I think came out. So a lot of this content is still from the last release. This is not a bug. This is a known process. This page only really gets created. I think when the release candidate starts it's towards the end of release candidate period. There is some, there is some processing and some conversations happening about this page. So it's definitely being developed on, but during the beta phase, it's definitely not something that is released with the, with the sort of updated version. So if you do see information on this page is incorrect. It's not a bug. It's kind of, it's not even a feature. It's just, it's known. This will be whatever the credits for the last release were. So, so those won't have changed it. But now I can start testing this release. So I can go to my posts, for example, and you can check if you are running. Let me just actually close my DevTools here. You can check if you're running the latest release by just checking at the bottom right hand side of your screen in your WordPress dashboard. Mine's quite long. So let me scroll down. There it is. You are using a development version 6.2 beta three. And then it says cool. Please stay updated. So what that means is as the new betas come out, the new betas will be available to update and you'll be able to update to them. Okay. And that's it. We're now running whatever the 6.3 beta code is. The WordPress core code has been updated. So now we can start testing. And I'm just going to check. So we've done that. We've done that. We've done that. Okay. So typically the first thing that I start doing is I start testing just default core functionality. And how much you test is really up to you as an individual. If you just want to go and have a look at the front end of the site and just check, do things work properly? Are my menus where they should be? Do I see any breaks depending on your content and your layout and your themes and whatever else? Spend maybe half an hour and see if you can find a break. Then go and have a look at maybe your appearance, see if you can still activate different themes, see if any bugs happen there, all of those kind of things. Then, you know, do things that you would commonly do on the site. So if it's your personal blog, make sure you can still create posts. Make sure you can type in things that you need to do, see what's different, see what's new. One of the changes that's coming to 6.2 is the fact that this settings icon has changed from the little gear to this sort of sidebar settings icon. But the functionality has stayed the same, so make sure that works and all those kinds of things. So just go through and test and do whatever you would like to do. Okay. The one thing that I forgot to do, and it's because I didn't leave myself a note, is I wanted to talk about debugging. So one of the things that I like to do when I'm testing is I like to enable WordPress debug. So let me show you what I mean by that when I say that I'm going to open up my code editor. And I'm going to open up the folder for the site, which I think I'm really in the learn press folder, so that's great. And then inside, let me move this out of the way, inside of the, where is it now? No, not there, I'm in the wrong folder completely. So one of the roots of the WordPress install is the wp-config file. This typically stores your database settings, if you're manually installing WordPress. It also typically installs your keys for your security and those things, your table prefix, and it has your debug settings. Now, by default, the WordPress debug settings are off. So by default, your local site may or may not look something like this, unless you've enabled it yourself manually. And this is what is known as debugging mode. If you enable this, it's going to start reporting errors on screen, which is not really ideal. What's better is to do it this way. And that is to define the following four constants. The first one is to set WP debug to true. Okay, and that basically enables debugging. But then set WP debug display to false. So what that means, it won't display on screen. So if there's a problem, it's not going to break the site. So if you are testing it on a site that's live, it's not going to break the site. And then set WP debug log to true. Now, there is a great support article here, which I'm going to copy into the chat if you want to read about how all this works. But effectively, what that does is it will then log any issues or errors or problems that it finds in a file called debug.log in your WP content directory. So let's open up that file. And yeah, we will see a whole bunch of issues. Okay. Now, none of these issues are related to anything we've done today. This is all when I was testing things out on the 9th of February, the 7th of February. But it's a good idea to enable debugging before you upgrade, run through whatever you're going to test on your WordPress site. So test your posts and pages, test whatever else, see if there are any errors logged. There shouldn't be because you're not running a beta version of WordPress. Then upgrade and enable debugging. And then while you're testing things out, keep an eye on the debug log file and see if any errors are logged. Because if an error is logged, it's probably a code error somewhere. If your site was fine before and there were no errors in the debug log and then after the upgrade there were errors, you can use those errors to look for problems. Okay. And what's great about that, when we get to logging issues in a second, if you can share the debug log information for that specific error with the ticket system, then folks can actually use that information to find the problem. So I highly recommend enabling debugging while you're testing. Because while you might not see any bugs, there might be PHP bugs that are not being logged. And the reason they wouldn't be logged is because WP debug is off. So with WP debug set to false, that suppresses all errors, which is great for a production environment. You don't want those errors to happen. You want them to not show. But if you can log them and fix them even better. So I always recommend switching these things on. The other one you can switch on is the script debug one. This is more for JavaScript related things. This won't log anything anyway. But what it will enable you to do is see if there are any errors that are being suppressed in your... Let me do this here. Where are we now? In your dev tools. So often there might be errors that are suppressed with script debug off. And if you switch on your console, you might see errors there. So those are two ways that you can find errors. I also do highly recommend, and I always do recommend this, to have these things enabled when you're developing locally. So if you're building a theme, if you're building a plugin, if you're building a client site and you're writing code in your functions.php or custom snippets or whatever, have these things on while you're developing and keep an eye on that debug log. If you can get to a point where nothing is being logged to your debug log, that's a win. Then you can say that site is ready for production. The other reason that's a good idea is because every time there... So there are different types of... And this is unrelated to testing WordPress. This is just a good tip to know. There are different levels of error in PHP world. There are errors, what are known as fatal errors. There are warnings and there are notices. Errors are site breaking bugs. So when that kind of error happens, it's probably going to crash the site. There might be a reason for a widescreen, what we call the widescreen of death. And you should very much fix those as soon as possible. Warnings and notices aren't going to crash your site. So it might be a deprecation notice or a warning about you doing something wrong, but the code still works. The problem with warnings and notices is if they are being suppressed, every time that error happens, it is adding an extra bit of processing time in your PHP execution because it picks up that there's an error and then PHP by default will go and try and log that error usually to either the web server or the PHP error log. But also it might try and log it to the screen and because you've got debugging off, you're not going to see that. But if there's an error that's happening regularly, let's say you've written something in... Let's say you've got a custom post type that you've registered and you've made an issue somewhere or what's happened to me before defining... A few times defining a constant like this and not putting the constant in quotes. PHP will actually still accept that but it will log a warning. And then every time your script, your page or whatever runs, that warning is going to get logged and it's just going to slow down and slow down your site. So it's always a good idea to have debugging on during development and during testing. Okay. I'm going to take another break for a sip of water. If anybody has any questions around all of that that we've just covered, otherwise we will look at the next steps. Grab the coffee by mistake. What it's worth. I don't think I have coffee left. I just grabbed the coffee cup because I'm so used to grabbing it. Okay. We don't seem to be any questions. I think we can move on. So the next thing is if you are a plug-in or theme developer, it is a good idea to test your plug-in and theme with the latest of WordPress when it's coming out. As I mentioned earlier, the best time to start doing it is when the beta is ready to be released because then you can see if there are conflicts. If your conflict is on your side, you can fix it. If the conflict is on WordPress's side, you can let WordPress folks know earlier rather than later. So in my plug-in list, I think I still have... No, I probably don't. The AMA plug-in. That's not going to be the best example, but I think there's this... Yeah, let's use the AMA plug-in. I can't use it. I don't think I have it packaged yet. Let's use one of my other plug-ins. Let's see if we can find one quickly. So the last plug-in that we maybe worked on was probably the form submissions API plug-in that we worked on. That's probably a good idea. No, I haven't. That one's not available as a package either. Maybe the LearnRest API one. So I'll share. Yes, there we go. We've got some releases there. So let me share this with you in the chat. This is really... You could use any plug-in for this, but I'm just using one that I've written myself because I don't know what's going to happen with 6.2. So if you'd like to download that plug-in now, I'm going to download that on my side. And then I'm going to test this. Now, when it comes to testing your plug-ins or your themes, I highly recommend that you... Sorry. That you look at setting up your test environment. We're not going to do that now. So that you're not physically installing the zip file from wherever you package it, but you're actually using a copy of the code that you work on. So for example, when I was working with a seriously simple podcasting plug-in, I would have the code checked out on my local environment using GitHub. And then I would go into my WordPress install and I would make a copy of that code inside of the plug-ins directory so that if I picked up things, I could then test and create branches and all of those things as opposed to just having to install the zip file every time. The downsides of that, and I've done this a couple of times, what I used to do is I used to have what's known as a sim link or a symbolic link, which is basically a shortcut. I used to create a shortcut to the development code inside of my plug-ins directory of my test site. And then I would work on it for a bit and I would make some changes and updates and when I update the version number, and then I might decide again, I want to uninstall this plug-in and I would then go to uninstall it, forgetting that I've got a sim link to my source code somewhere and I would end up nuking my source code. Another good reason to use version control, because then I could just check out the code again, but depending on how you want to set that up, just make sure that you're working with your latest version of your code, because what you don't want to have happen is you're testing things, but you're maybe working on some feature and you're testing with that feature and then you pick up a bug and then you forget what you're working on. The other thing we used to do, and this is something, I'm not sure if I'm going to be able to find this. Maybe I will be able to find it. The same person who... Yes, no. Okay, let's try it this way. The same person who developed the WordPress beta tested plug-in, Andy Fragan. Dr. Andy Fragan, he's an ER surgeon and he builds plug-ins. He wrote this thing called the GetUpData plug-in. So what this does is this allows you to install this plug-in on your WordPress site. Let me share this in the chat. You install this plug-in on your WordPress site or anybody else who wants to test your plug-in, maybe you've got a testing team within your company or whatever, and you can then connect the plug-in to your GitHub repository, your Bitbucket repository, your GitLab repository, and it will then pull whatever... So you can tag a beta version and it'll pull that code into your local WordPress install. So it's a great way to test the beta versions of your plug-ins with the beta versions of WordPress. Not related to testing WordPress, I'm just sharing this with anybody who's a developer out there who wants to use it. Okay. I think I've downloaded the plug-in, so let's install it now. And I'm going to just upload it here using the plug-ins. If you're doing this along with me, please let me know how it goes on your side. I'm just going to install that. And I'm going to install it and then activate it. So here, okay, it looks like I've already got a version on here. That's fine. I'll just replace the currently uploaded version. And then once that's done, I'm going to hop back over to the plug-in installer. And as soon as that's done, I'm going to check out the debug log. I want to see if the process of installing and activating this plug-in calls any errors. Because it was already installed, I may want to deactivate it and then reactivate it and see what happens. So here is the LearnRest API plug-in at the bottom here. So now I will deactivate this. And then I will reactivate it because sometimes, and this has happened to me before, sometimes you might add functionality to a plug-in and you're not testing the deactivation and activation flow when a new user comes along and a bug might creep in. So I always deactivate and then reactivate that plug-in. And immediately once it's activated, I then check the debug log. Cool, no errors. So that's already a first step that I do. It's a good idea to think about these common steps and maybe write them down as a checklist. This is something we did internally at Castles. We had a whole testing page of all the different steps we did. And then eventually we turned that testing page into actual unit tests, code tests that we could just run every time. But a good place to start is just to write down all the steps that you'll follow. And then what I will do now... Okay, so Adrienne got errors when she uploaded and activated my plug-in. So that's great. So there's either a plug-in in my code, which is very possible, or there's another plug-in that's conflicting. So now we're starting to see that errors happen. And today is one of those cool days where I don't mind errors because that's the point of testing. So Adrienne, you may need to disable that. I apologize if there are errors. We're not going to fix those errors today, but it's good that you're seeing the errors because now you could possibly log that as an issue. Cool. It could be a conflict and I'll tell you why. You might have one of my other workshop plug-ins installed and remember there was a stage where I was using the same functions in my networks. It probably is something like that. So yeah, don't... Word of warning. Don't ever use my workshop plug-ins as a good example of best practices because I'll often use the same initialization prefixes or whatever. I really shouldn't. I really should start making sure they're unique, but I don't tend to have them installed at the same time. So just be aware of that. Okay, let's move back onto here. So now what I would typically... Okay, so there's a question. I'm going to stop and deal with the question. Do we have to create this debug log file by ourselves or will this be created as soon as the error occurs? I'm not having this file in my folder. Okay, that's a good question. One of the reasons why it might not be created in that folder is because the user that is running your WordPress install depending on what you're using doesn't have a mission to create that folder. Sorry, that file. If you're not seeing that file, they go ahead and create it and then WordPress should then be able to write to it. There's a way that you can test once you've created it and where the WordPress is able to write to it. And I'll show you that now quickly because it's useful to know. With these settings enabled, if you create a very simple plugin and I'm going to use the LearnRest API plugin that I just installed, you can do something like this. You can go error log, which is the PHP function to log an error. And you can just log some kind of arbitrary message. So let's just say an error has happened like that. And now with that enabled, if I make any kind of request, it should log that error to the debug log. So let's check that. If I open up my debug log, there we go. An error has happened. So if you do that in a plugin somewhere, just at the top level of a plugin, just underneath the plugin header, and you're not seeing the error log to that debug log file. It means that your WordPress install can't write to that file for some reason. Unfortunately, I'm not able to help you with how to debug that. You'd have to check with whatever your local environment setup is. If it's something like local by WP or local, or what are the others? MAMP, WAMP, whatever system you have set up, you might need to check whether the user that is running the WordPress site can write to that file. But generally, when you create the debug.log file, if you have the configuration set up and you're configuring it, it should then be able to write it. So that's something you can try. As I say, if it doesn't work, unfortunately, I can't. I saw something I can easily debug. I don't know all the systems in all the local environments. Adrian says it's either SQL by your create block theme. So now this is actually tickling me. I want to see if one of those is going to give me an issue. So let me see if I have, I don't have either install. So there's create block theme. So let me update that. And then let me add SQL buddy as well and see if I get an error. So SQL buddy is the one from the folks delicious. Maybe it's two words. Let's install that. Because now I'm interested to know what Adrian is seeing. And let's install an active deprecated string of place. Okay, there we go. It's create block theme. Okay, let me see if I get a similar error on my side. So let me deactivate REST API and let me activate REST API. And let me check my debug. Okay, I'm not seeing it. So let me just see a local sites. The intro public includes functions. String replace parsing to three is deprecated. Yeah, it's interesting. Which version of PHP would it have to do something with the version of PHP? It could also be a PHP version thing. Yeah, so it's one of those things where, you know, this is where we would start logging this and seeing if people give us feedback and that kind of thing. Today is not, today is not about debugging issues. Maybe we should do a session around this. So Adrian remind us about this maybe in future we can do a plugin config session. But the short and simple answer is default theme, disable all other plugins and see if Eric continues and then enable one plugin at a time and see when Eric kicks in. And then that'll, that'll indicate where the problem is. But fun, fun one for finding. Okay. So Bob says great. Errors are coming to the debug log. Excellent. So that's how you can do it create the file, test it yourself. And if you know it's working then you're good to go. Okay. Awesome. So we're learning about how to find errors and how to find bugs. This is already a good session. Okay. So that's how I would test a personal plugin that I own. That's how I would test a theme that I own and manage. I might even, test some of my commonly used plugins this way for WordPress core. That's another cool way to contribute to the WordPress ecosystem is if you have plugins that you use regularly, especially if you know that there are plugins that are maintained by contributors. They're not behind like a paid company like WP Migrate or Yoast or one of those. Test those plugins and see if they have conflicts and then send those tests to the plugin developer so that they can, you know, help fix it all goes around. Cool. Now let's talk about new developer features. So how do we find them? And how do we test them? So there is a link that I have shared with you in the slides. It's the link. I'm moving my slides around you. It's the link just below the WordPress beta test link. I'm going to pop it into the chat here. And this is in the WordPress test team block. So there is a test team within WordPress and they just test WordPress. And effectively by testing WordPress for a release, you are part of that team whether you signed up for it or not. But anybody who helps to test WordPress is doing so. There is a core test channel in Slack where for example, Adrian, you could pop in there and you could say, hey folks, I was testing WordPress 6.2 and I saw this error. Do you think this is something that you could help me with? And they might be able to help you figure out where the error is or not. I don't know. I've never spent a lot of time in the core test team but usually they'll help with answering questions. And they will typically have a blog post that will come out and you'll notice that their blog post was on the 7th of February. And if we have a look at, we just find the release cycle, beta one came out on the 7th of February. So they usually time that post with the first beta. Usually on the same day or around that time. And they talk about what are the things that are coming to WordPress that you can help test with. They talk about setting up a testing environment. They talk about the WordPress beta test plug-in. So if you forget this on the 7th of February and if we have a look at we just find the release cycle, beta one came out on the 7th of February. They talk about the process of setting it up. And then they give you some tips. They say test across different browsers, test in different languages, compare features on different screen sizes, and all of those kind of things. And then they have what they call key features to test. So these are features that are coming up in 6.2 that they would love to get feedback on. So there are new things that are coming up in 6.2 that they would love to get feedback on. So there are new things that are coming up in 6.2 that they would love to get feedback on. So there are new things like browse mode. So with the release of 6.2, the site editor has been completely reimagined, blah, blah, blah, blah, blah, there's information on how to test and links to different tickets. The removing of the beta label, template parts and reusable blocks colorization. So if you're looking for something to test, this blog post is usually a great place to look for something, go and give it a test. If you're somebody who's working. So here's one, for example, that is talking about settings and styles. And they're talking about experimental code in the block editor. So if you're a block coder, you can go and test these things out. They're talking about inspector controls and how you can define things there. So if you have a block that's using inspector controls, you can test that out. So this post is usually a great place to find different things to test. They usually have articles linked through about what these different things are. They have links to different issues either on GitHub or things that are coming. And if you want to help test WordPress, just let's say you've got a couple hours in your day and you want to test, just go through this blog post and test all the different things out and see which one you do or don't like. Now, the one about inspector controls I thought was quite interesting. There's a new styles group added to inspector controls that enables you to do something. And that's not really what I'm going to test today because it's a little bit difficult. But I'm just trying to look through and see if I can find something. Distraction free writing might be a fun one to test. So it says the new focus mode offers a more concentrated writing experience by hiding unnecessary elements of the interface. When enabled, all sidebars are closed and toolbars become less visible, allowing your content to take the spotlight. And there's a little video where I'm going to turn the sound off. But if we watch the video, we can see that there's something for us to test right now. So if I hop on over to my WordPress install and I go to a post, for example, and let me just find this post over here and click on the options button and there's distraction free mode. And there it is. That's what it looks like. Now the reason it's not looking exactly like the way they showed it is because I also have something else disabled. How do I get out of distraction free mode? I can't see a button to there it is. It comes down when I scroll up. Okay. So maybe that was something that I want to mention. I don't know. Oh, it's when I mouse over. Okay. So now if I hadn't found that, maybe I could lock this, lock this as a back when I switch to distraction free mode. I can't see a way to get out of it and then somebody might come back and say, I have full screen mode disabled by default. So some of you might recognize this as your default post editor. It's full screen mode in the editor. It was released in, I think it was version 6.0 of WordPress. I have it off on purpose, or at least by default because I like to have this view post link at the top here. But what's cool now is I can now switch it on and switch to distraction free mode. Apologies. And I can see what it's going to do. And the first thing I notice is, okay, I need to mouse up to get my menu back. That's great. Okay, I like the way that works. I, what I don't like about it is I can't change my blocks. I don't see a way to switch this classic block to a default block. So maybe I'll switch out of distraction mode to see. Okay, that's still not there. Maybe that's not a bug. Maybe it's a feature I don't know. And I enable this. There it is. It's back there. So with distraction mode off, my toolbar is available with distraction mode on. My toolbar doesn't become a bit. Now that may or may not be a bug. I don't know. I'm just going to convert this to blocks quickly so that I have blocks everywhere. And I want to just, and now what I'll do is I'll go back and I'll see is that intended. So let's have a look at the video. And it says when enabled all sidebars are closed and all toolbars become less visible. So maybe it's intended. I don't know. Let's have a look. Let me have a look at the issue that's linked. And I'll go up over here and I'll see what that says. And this is literally what I would do when I'm testing this. So I'll see, okay, fine. It talks about introducing it. And I'll go up over here and I'll see what that says. And this is literally what I would do when I'm testing this. I'll go up over here and I'll see what that says. And this is introducing it. It hides the top toolbar. It removes many top toolbar buttons, closes sidebars, hides the insertion pointing to gate. Okay. So it is supposed to hide the block toolbar. That is the required functionality of this feature. Personally, I would prefer the toolbar to stay even in distraction-free mode. So maybe I would prefer the toolbar to stay even in distraction-free mode. But that's down to personal choices to how you want things to happen. But I've tested it. I've tested how it works and now understand what it does. Go back to my post. I guess if I think about it, it's supposed to be distraction-free. So I want to just be able to sit down and type. And what's interesting, let me take you all back a step. Those of you who were here for my REST API workshop, you will remember that I had enabled the Custom Fields panel. By default, a lot of folks might have that panel disabled. They're not using custom fields. And so in that instance, distraction-free mode works pretty well because then I can't see those custom fields because I have them disabled. But what if I have them enabled? What if I've chosen custom fields? Should the custom fields be hidden in distraction mode? That's interesting. I don't know the answer to that, but maybe that's a bug I could log. Maybe that was something that the developer team who were working on this didn't think about. And what I would do at this point in time is I would actually say I've tested this out today and I noticed that with custom fields panel enabled, the custom fields don't get hidden in distraction-free mode. Maybe they should. And I would then be giving that feedback to the team and they might then agree and they might then say, well, yes, if panels are disabled, let's hide them. So that's already a way that I can start giving this feedback back during the testing process. So this is actually cool. We found something that may or may not be a bug, but it's still a good idea to have this conversation so that the discussion happens, which leads into our next step of where do we log these things? Okay. So believe it or not, I'll share this with you folks. I did not pick this issue beforehand. This was pure luck that we found this, but this is how testing happens. Sometimes you stumble across things. I'm very, very excited about this. Okay. So now let's talk about the process of let's go back to our objectives. Before we do that, any other questions on what we've done so far? Linda says we don't have to be full on developers. Absolutely. And that's why we do these testing sessions. You don't have to be a developer to test these things. You just have to be somebody who uses WordPress and then use WordPress the way you're used to using it, but test out these new features and give feedback. I can't guarantee the feedback will be used. I will say that because it just depends on time to give the feedback because you might find that in this instance I don't know what's going to happen. We might find that they knew this was coming and they agree that it should be done that way. We might find they didn't think to test it and they agree that it should be hidden. I don't know, but at least we're giving that feedback. We're helping to improve WordPress. So this is going to be a little bit difficult for me now so I apologize in advance. I need to talk about this in a little bit. So in this distraction free writing section and you'll notice this with all the other features coming to WordPress. There is usually a link either to a GitHub issue or what's known as a track ticket. So before we actually do the logging of what we've just discovered, let's talk about those two things. So I'm going to scroll right up to the top here and go to the WordPress Gutenberg GitHub project. It's basically a code repository and issue tracker and various other things. The Gutenberg project. In other words, the editor, the site editor, the theme editor that's all under Gutenberg is developed publicly on GitHub. As I mentioned earlier, one of the reasons for that is because the Gutenberg projects tends to run a little bit ahead of WordPress call and by the time a WordPress release comes out. Whatever's included in the WordPress release was finished maybe a few months ago. And the Gutenberg developers are working on the next set of features. However, WordPress itself, the core WordPress has its own issue tracker called track. That's the software that's been used since practically day one. And this is the place where you can create issues that you find in either the current version of WordPress or if you're testing one of the beta or RC releases. Now, when it comes to where do I log bugs? In my opinion, if you are working on something on this help test WordPress page, one of the features that for example that we're looking at now, they will usually link to the related item. In this case, it is a pull request on GitHub. And then my suggestion would be that that would be the best usually would be the best place to log feedback. However, you will notice that the item is marked as merged, which means this code was merged into what's known as like the main branch. And so therefore logging any kind of conversation here might not get followed up because this is considered done closed moving on. You'll notice that the last bit of conversations around here were in November 2022. So because of that what I would do if I was log in this bug is I would log it in WordPress track because that's related to an upcoming release. And what you can do is if you create a new ticket and let's actually go one step back. Sorry, before we actually create a ticket. The other thing that you will need to be able to do to log a ticket in track is you will need what's known as a WordPress profile. Now, if you've done an interaction on the WordPress.org site, you've joined any of the teams, you probably have a WordPress.org profile. If you don't, you can create one very quickly with this link. I will paste this in the chat as well. This will then enable you to log tickets in the issue tracker. If anybody's interested, my profile is that one. If I could change my username, I would, but I've had it for so long now that there's just unfortunately nowhere around it. But basically the WordPress profile logs all of your contributions. It logs all of your activity. Anything to do with WordPress and contributing to WordPress. Once you have registered an item, and if you don't have a profile now, you're welcome to register, but just watch me as I log the issue. If you're, if you're testing for one of the betas or one of the release candidates for a release, I recommend doing it in track. The reason I recommend doing that because the WordPress team is in the release cycle, they are regularly keeping an eye on track for any new things that are locked because they're expecting folks. They're asking folks to test. So they're expecting first log issues. In fact, if we have a look at this help test WordPress blog post, they actually talk about there's more detailed steps here, beta testing. If we open that up, let me share that in the chat. There's more detailed information there. And if we scroll down, there is a whole page on where to report bugs. Or there's an alpha, beta support for them. So there's two places you can you can do things. The first one is. Talking about reporting bugs and it talks about track and the bug tracker and how that all works. I'm not going to share these links because these come from the article that I just shared with you. Beta testing article. The other one is the alpha, beta support for them. So here, for example, if we look at Adrian's problem earlier, here might be a good, a good place for her to ask the question and say, I installed the beta tester. I got this error. I'm not sure if this is a WordPress beta related issue. Or maybe it's a plug-in conflict. Can somebody please help me? And there are folks that contribute to the support team. So it's another volunteer team. And they will hopefully be able to come along and help you out. It does sometimes take a couple of days for folks to respond to your support questions. So you do have to kind of give it some time. But if you're asking those kind of questions, this is a good place to ask questions around bugs that you might encounter. So if you're not sure that it's a bug and you want to just verify it, and that's another reason why Linda's question about, do we have to be developers to test it? No. Somebody here will help you figure that out because you are helping test WordPress for a release. So if you're not sure, this is a good place to start. If you are sure, if you're pretty sure this is a bug or you think it's a bug, then you go to track and you create a new ticket. And I'm going to go through that process with you very quickly. If you have a WordPress profile and you want to just do that now with me, you're more than welcome to but you can just very quickly watch it. So we click on the create a new ticket button. It's going to ask us to log in. I'm going to log in with my profile just for the sake of now. Thank goodness for password managers. And then it does say to you at the top, are you in the right place? This is not for support. This is to log what you believe is a bug. And then there's some other pieces of information. And then you start with very simply a summary. So I'm not going to log this ticket now and I'll tell you why. My personal first step just because I've been around the WordPress environment for a number of years is I first go into the core edit. In this case, it'll be the core editor channel in Slack. Let me actually show you that now so you can see what that looks like. I have Slack opened up to the WordPress community. So don't mind sharing my screen. So this is the core editor Slack. This is the team that works on the editor. And what I will then do is in here I will pop a question. I will say, Hey folks, I was busy testing WordPress. I was testing this feature. This is what happened. Is this a bug or is this expected? And the reason I do that is because typically in a release cycle, there are more people active in the core editor channel. And you will see we might even see him. I don't know if we're going to find him up here, but we might even see activity from the person who created this pull request. I don't know if I'm going to find him. No, he's not here lately. But anyway, his name is, let's see if we can go back to that. I don't think I've got that anymore. Yes, I do. Here it is. I'm going to scroll right to the top. Sorry. Well, I'm just Andrea is his name and he's also in that chat. So it's a good place to ask the question because then he might even come in and say, oh, thanks for testing. And, you know, this is what it's supposed to be. So my process is to ask here, but that's because I feel comfortable to do so. If you don't feel comfortable to do so in Slack, that's fine. Ask in the forums or post a ticket. Anyway, once I feel like I have got a valid ticket, I then go to track and I'll give it a summary. And for the summary, try and keep it short, but explanatory. So in this case, I might say something like distraction free mode does not disable a custom fields panel. So that gives a nice description of what's happened. The reporter will be your logged in username. And then in the description, I will say, I was testing this feature out. I'm not going to type it all up now, but I'll say I was testing this feature out and I try and give as much information as I can. I had the custom fields panel enabled because I was working with some custom fields. When I just, when I enable distraction free mode, the custom fields panel stayed. I would have expected it to also disappear. Then I will take a screenshot of whatever I was testing. So here's the thing. And I will take the screenshot. And then I will also say how to reproduce. So new WordPress install or current WordPress install edit, go into, into, um, go into the editor options, open the preference, click on panels, enable custom fields. And the reason I'm doing this is because the person who triages or the person who reviews my ticket during a bug scrub, what's known as a bug scrub, might not know about custom fields. They might be new to WordPress. They never use custom fields, but they're part of the testing or the triage team. So for them to be able to validate it, they need to follow the same steps. So that's what I will typically do. I will include as much information as I can. And then I'm going to include a screenshot or two. And then I'm going to, I will include as much information as I can. And then I will include a screenshot or two, um, about, about what I saw. And then the other thing that I will do is here where it's got the version dropdown. I will make sure to select the right version. And you will notice that they only have the latest version or trunk. So I will select trunk for that one. Um, and then I just want to priority. Priority I will leave as normal severity. I will leave as normal unless it's like really breaking. And the components, I will make sure to select the correct component. So in this case, it's the editor. Um, workflow keywords, I will leave. And then I will usually leave contributor focus as well. I will let the triage team deal with all of that. I will include in my description that I was testing. Six point and I will go and get, uh, let's actually disable destruction free. So we can get that. Um, I will go and get the version number that I'm working on. So in this case, six point two beta three, I will go and get that version number and include it in the ticket. Um, so that folks know that's the version I was working on. Um, because it's helpful to that information. And then I will simply leave that as create. So here the status is create. Um, and what's nice is you can then preview this ticket. So if you click on the preview button, you will get an idea of what it's going to look like. Now I haven't typed into description, obviously, but if I, if there was a description, it's actually pop in some text over here. So let's say I was testing destruction. Free mode. And we'll leave it like that. We'll hit preview. Um, and right at the bottom here, then it shows me what my ticket is going to look like. And then once I'm happy with it, I'm not going to do it now, but I'll click create ticket. Now the nice thing about when you create a ticket, number one, if you have, if you have, never contributed by creating a ticket before you'll get a nice. Thank you and welcome. If it turns out that your ticket is valid and your ticket ends up getting fixed for the next release, you will be included in the contributor list. On the credits. Um, when that version of WordPress comes out. So even if it's a small bug like that, that you've logged in the credits, right at the bottom underneath the note with your contributors, there will be a whole list of people that have contributed. And you will be included in that list. So that's kind of cool. Nice little brain rights. Um, I don't think I contributed to 6.1. Uh, oh, no, there I am. I did. So I did something in 6.1. I think maybe it was a bug that I logged again during a testing phase. I can't remember. Um, but it's really cool to see your name in the credits for a WordPress release. So it's another good reason to get involved in testing. So don't go to all log this, but it's really cool to see your name in the credits for a WordPress release. So don't go to all log this bag now that we found. That's mine. Um, but, but do this process and it's a great way to get involved and get contributing to WordPress. So you don't have to be a developer to contribute to WordPress core. You can just be logging issues that you find. They do have to be valid issues. So don't log like things that aren't problems, but if you're testing things and you do find problems, do log them. And then, and then you, if they are valid and they haven't been logged by somebody else, you should get credit for that. Okay. Um, that covers the last two where to ask questions and where to log bugs. The other thing I wanted to mention, if you're testing specifically the editor and this, for example, hadn't been merged, you might want it to add it over here. Um, I do also understand though for some folks having a GitHub account is problematic. There are, there are concerns around GitHub in various spaces. I respect that. So then track is your best place. Um, if the ticket needs to be created in GitHub, then somebody will create it in GitHub for you if needed. Uh, but track is usually the best place to log, log any bugs that you do find for WordPress release. Okay. Any questions around how to log issues, how to log tickets, um, and what to do around that before we, before we wrap up. Okay. I have great to, um, um, uh, that is this, this particular, uh, ticket, this particular PR was merged in, in Gita. So just in case, we are comfortable with GitHub. Is it possible that we can open a new PR? Uh, um, so in this, that's a good question. So in this instance, what I would recommend for this example, what I would do is as I say, I would, I would log, I would ask the question in this in the, in the court. It's a slack. So I was testing this today. Is this a bug? Do you think this is a bug? Um, and you'll notice that if we go back to the slack, you will notice that in the core editor channel, um, they will often have, uh, often have core editor chats. The last one happened yesterday at 4 p.m. My time. That's a perfect opportunity to ask that question. Um, I would then ask that question. If, and if somebody confirms this is yes, that does look like a bug. Then it's perfectly acceptable to go ahead. And firstly, log the issue in the GitHub environment. And then if you think you have a fix for it to then, to then create a pull request. The cool thing about the way WordPress is working is that WordPress core and Gutenberg are kind of working together. So if you do do the things in the, the Gutenberg repository, you will also be included in the credits for whenever that fix comes out. So if it's part of a release or whatever. Um, so yes, if you are a developer and you're comfortable with working on, on the Gutenberg block editor and, and you confirm that it is a bug, you're welcome to go and create a PR here. This is just like any other open source repository. Anybody can come along and create issues, create PRs. It is a bit of a process. It's not going to be fixed overnight. It won't be merged overnight. There'll be some discussion around it. It's not like when you're working for a company where things happen very quickly. Open source can be a lot slower. Uh, but yes, that's, that's a perfect thing to do. That's a great, a great way to do it. Um, Awesome. Thank you for that question. Uh, Uh, Cool. Okay. That is my bit for today. Uh, hopefully I have inspired you to, to think about testing WordPress in the future. Um, as I say, I tend to do this on my personal blog around about release cycle time. Uh, so I keep an eye on the release cycle and I'm just trying to think if I've still got that. I don't have that page open anymore. Um, Right. Here it is. Uh, so I will, I'll, I'll, I'll just leave it like that. And then if I happen to pick something up, I'll log it. Um, that's a great way just if you don't have a lot of time to test, just install it on a personal blog. Uh, something that's not super important. Um, You will need to be able to install plugins. So I, if you, depending on, if you're on WordPress.com, depending on what environment you have, you might not be able to do that. But if you're on any kind of hosting, you might not be able to do that. Um, install the beta tester, set it up. The other thing that I wanted to show you before we wrap up, is it is possible to roll back to a default version of WordPress, to a stable version of WordPress. So again, you go into the tools menu, you go back to the beta testing menu item. And you simply just then say, I want to go back to the point release. I don't want to be able to do that. But if you're on any kind of hosting other platform where you can install, install plugins. Um, you go back to the point release. I don't want to be running the bleeding edge. And if you then save your changes there, um, now it'll say I'm ready to go to 6.1.2 alpha, which is fine. Uh, and then I'm going to, what I'm going to do now is I'm going to, um, update that. Yeah. Yeah. Sorry. We just go back. Asking a question. Yeah, it's been answered. Okay. Yeah, cool. Um, and then I'm just going to go and I'm going to do the update there. And. I don't think this is the way I want to do it. Uh, yeah, I do want to download. I'm using a set of changes there. And now I can update. Now this is going to say, yeah, I get the option to reinstall 6.1.1. So I don't want to go to the latest 6.1 90. I want 6.1.1. I want the latest stable version. So I click on that button. It will then download the stable version. Reinstall it over my current beta version. And I will go back to the stable version. Um, so just getting back to that question about testing on local and Monzer did on today, but effectively that's one of the reasons why I like using the plugin is it should work on any WordPress installation. So whether it's a local on a server on a staging environment behind basic or on Wamp on MAMP on local on Lara gone, whatever all these other development environments are, it should work. Um, things like local and what's the other one, Dev Kinster and those, I think they also have an option without using the plugin where you can actually just set, you can create a new WordPress install using one of the bases. I think I can't remember 100%. Uh, but yes, the plugin should just work anywhere. And basically all it does is it, it's gone back to 6.11. Let me just show you all it effectively does is it reinstalls all the files in the W includes folder. So it takes whatever is there currently and replaces it, whatever the version is that you're installing, that's effectively all it does. Um, the other ways you can do it, if you look at that, um, I see there are questions there. I'll check them now, but while I'm just chatting about this, if you look at this testing, um, document that we were looking at earlier, there are also environments that they talk about. So you can use the beta tester plugin. Um, I think it was this one over here. If you're somebody who's comfortable using WPCI, you can do it that way as well. So here's the WPCI command. So if you use that, you can use that way as well. Um, but I find the beta tester plugin to just be the easiest, um, to get it, to get it to work. Okay. Um, Linda. Yeah. So people who use WordPress.com and don't have a plan that allows plugins. You can test in local. Absolutely. So that's been answered. You can test in a sandbox, taste WP, any of these environments you can test in. Um, that's what's really cool about the plugin. Okay. Um, so please go forth and test. Um, test it on a local, test it with plugins, uh, test it on your site, make a copy of your site locally, test it there. Uh, because the more people that we have testing WordPress before release, the more we can find bugs. Um, you will notice in a, in any kind of WordPress release cycle, there's usually like a major release, like a 6.2 coming up. And then a few weeks after there's a 6.2 one. Uh, and that's because once 6.2 comes out and folks start updating it on their sites, they start picking up edge case bugs that nobody thought about. And, and the more we can get those things picked up earlier, the less chance there is or the least amount of bugs there might be for a 6.1 or a 6.2 or 6.2 or whatever. Um, so I always suggest to people testing the new release of WordPress is one of the easiest ways to contribute back to WordPress. Even if you don't log any bucks, if you just test common functionality, you test editor, you test the new features. Um, you know, you keep an eye on the new features coming out, you test your themes, you test your plugins. That's something. Uh, test upgrading that process. Um, that's that's something and it's helping with that process of testing WordPress. Okay. Thank you all for joining me today. I hope that you've learned something about how to test WordPress today. I hope you enjoyed it and it's something you're inspired to do. If nothing else, the credits, the link in the credits to your profile is always cool. Um, I probably will do the session again when 6.3 is coming out. Uh, maybe we, maybe there's some other features we can take it. I'm definitely going to have a look at this thing that I think might be a bag and follow up and I'll let you, if you, if you join me next week Thursday, I'll let you know what happened out of that, or maybe I'll share it online or something. I'm not sure, but enjoy the rest of your Thursday. Enjoy the rest of your week and your weekend and I will see you next week.