 All right. Good afternoon. Good evening. Good morning. Good day wherever you are in the world. Welcome to this Thursday online workshop. I'm a little bit delayed today, I'll be honest. I returned from a trip to the United States on Monday, and I am still busy recovering from a bit of jet lag. So I apologize to anybody if I am not my usual chipper self, which may or may not be a good thing because I do tend to talk very fast. And so maybe I'll be nice and slow today. While you are joining us today, please do let us know either in the chat or you're welcome to unmute and say hi and let us know where you're from. I see a few familiar names and a few names that are new to these workshops that I'm familiar to so welcome everybody. I'd like to make a specific welcome to Birgit Olsen who is joining us today. I met Birgit for the first time. We've known each other online for a while, but I had the opportunity to meet her in person at WordCamp Europe, so that was lovely. We didn't get a chance to talk much because I was bouncing all over the place, but the next time I'm up that side of the world I'll get to have better chats with her. Jean says Hawaii hangover. Yes, a little bit along those lines. Tracy asked me just before we started, where's my tan? We didn't spend a lot of time out in the sun. We had one activity day and we spent that day going for a hike and then the afternoon we went to the beach. But the rest of the time we were indoors doing work related things. So it wasn't much sun tanning going on. Mark says hi, Adrian says give yourself some grace, Jet Lake from such a long distance is brutal. Yes, I had no idea. I'm learning how brutal it can be. So it's quite a thing. We've got Gurkut from Germany, Steven from Germany, Laura from North Carolina. I went to Hawaii, Laura. It was our team meetup and I had the opportunity to go to Hawaii. And I discovered that it is very hot there. It was 30 degrees Celsius. I don't know what that is in Fahrenheit, but it was 30 degrees Celsius practically every day. By 9am it was 26 degrees Celsius, which is pretty warm. But that's very worth for the week last week. I'm from New Jersey, Hygiene. I'm from Florida, welcome. I'm just going to make a change there. Linda says hi from Virginia. Linda says, actually Linda, not sure I got signed up through this. Don't worry, I do things like that all the time with Zoom. Zoom is a weird piece sometimes. It says, temperatures like it was in Athens during, yes, temperatures like Athens, yes, during WCU. It's a weird thing for me because when I do travel to the northern hemisphere this time of year, I go from winter to summer and then back to winter. And it's such a weird feeling landing in Cape Town that's like, you know, 16 degrees or whatever at five in the afternoon, which was rather strange. Valerie says, welcome. Good morning from Oklahoma. John's from Chicago. Great, we've got folks from all over the world. So hopefully the extra half an hour has given you a little bit of extra time today. The reason I moved out by half an hour is because I had some other conflicts going on. So hopefully this works for everybody. Linda says we've got a mini heatwave here in Virginia. Yeah, based on what I experienced in Hawaii it is very warm outside of the world. I'm also suffering a little bit from some nasal congestion, which I think is related to the jet lag. So if I have to break and blow my nose in a second, I do apologize. I will turn my mic off when that happens. Because I tend to have a very loud nasal nose blowing effect going on, which I've now just told the world via WordPress TV in the skyline. Okay, so today we are going to be looking at testing WordPress 6.3. I know that court needed a session on this sometime last week. This is going to be another session along those lines. I think it's always a very good idea to test a new version of WordPress before it gets released. I usually try and test at around about beta one, beta two, if I can. But I'm a little bit late this week with that. I think they're on beta three already. We'll go and check that in a second. But it's always a good idea to test WordPress 6.3 for a couple of reasons, which we'll dive into as we continue with today's session. But as always, a few announcements before we continue. Thank you to Tracy, who's co-hosting with me here today. And welcome again to everybody who has joined us. Please let me know Tracy says we're on RC2 right now. We're even later than I thought. Normally I like to start testing during the beta phase. Let me know if you can't see what is on my screen. You should see the announcement slide right now. So if you don't see that slide, please let me know and I'll just reinitialize the screen share. We are presenting in focus mode today. That basically means that you can see me and Tracy, but you can't see each other. And that's just to prevent any kind of zoom bombing that might happen. Leonardo, I see your question now I'll get to that in a second. If you have any questions, as Linda just did, you're welcome to either post them in the chat or unmute to ask questions. And I will make a point of keeping an eye on the chat and swinging back to them as I take breaks. Then if you want to test along with me today, if you want to follow along the process that I'm following, please make sure your local WordPress install is ready. If I'm going too fast, please let me know. Sometimes talk a bit fast. So just ping me or just say, Hey, you're going too fast. Slow down. I didn't catch that. As always, we will be posting the session to WordPress TV afterwards. And for more WordPress tutorials and courses, you can visit learn.wordpress.org and check out all the cool content there. And then finally, if you're looking for WordPress developer news and interesting articles, you can go to developer.wordpress.org slash news it's a new developer blog that was released a few months ago. There's some interesting things going on over there. Leonid, in terms of your question, if I want to upgrade from 6.1, should I upgrade to 6.2 first? No, you shouldn't have to. You should be able to upgrade straight from 6.1 to 6.3. I don't recommend that. I do recommend upgrading to 6.2 and making sure that you've tested it works first and then upgrading to 6.3 but there's nothing stopping you upgrading straight from 6.1 to 6.3. In fact, as far as I know, I had a conversation with somebody about this a few years ago. There was somebody who or there is somebody who during the testing phases of the new WordPress releases, they upgrade from, I think it's WordPress 3.4, 3.8 something. They test the upgrade all the way to whatever the latest releases. Just to test that process works in case anybody's still running 3.8 and they want to upgrade. As Tracy points out, that was my next point. Do try it on a development site first. So if you're testing this on your live site, I don't recommend that at all. I say that with a caveat. I'll share the caveat in a second. But if you're testing it on client production sites or anything like that, I don't recommend testing upgrades there. Create a staging site, create a local development version of the site and then run the upgrades there to test. And this counts for anything. This counts for plugins, themes, WordPress versions, any software, any software, and that includes WordPress has bugs. I still to this day when I have to update my Microsoft installs, my Windows installs, I always expect things to go wrong. So A, try it on a development site first and B, have a rollback process. So have a backup setup, copy of the site setups that you can rollback if you need to. So what we'll be doing today, we'll just be testing the WordPress version. So I'll go through the process of how you can rollback once you've done the tests. But I do recommend doing this all on local versions or local copies of the site or staging environments and not doing it on production sites. The one caveat I have to that is that I generally run my personal sites on the latest version. So the minute 6.3 comes out, I'll update my site to whatever sort of stable 6.3. Because it's my personal blog and I don't mind if it falls over. I just like to keep it on the latest and greatest. I know Matt does the same thing. I know that most of the WordPress.org sites are running the most recent version of WordPress. I think they even run like the bleeding edge releases. So there are some instances where you can run it, but I wouldn't recommend it for any client production sites. Birgit says there for testing purposes is helpful testing from older versions and development sites like real sites will maybe have skipped previous versions. There's a perfect example. So there's no reason you couldn't do it. Just be aware of the possible downsides. Then a quick question time before we get answered. Before we get going on a scale of one to 10 and Leonardo did see your question there. So we'll get back to that in a second on a scale of one to 10. How well do you know this topic about testing the latest release of WordPress? I'd like to get a feel from the folks that are joining us today on a scale of one to five. Where do you where do you fit in? I am personally I consider myself a fall because I always believe there's always something new I can learn and I always do learn something new whenever I'm doing things. So I consider myself a fall. Adrian says she's a one. Laura says she's a three Emily says she's a zero Emily. Are you sure about that? Leonid says a three. Birgit's four. Gina's three. So Bum's two. John says two. Andrew says two. Adrian says zero. And Mark says two. Okay, so we've got some folks who've done this before. They've got some ideas. That's great. I love I love knowing where everybody is. And hopefully today you'll maybe bump up a number or you'll just confirm your knowledge. But hopefully there's something that you can that you can get out of this. I just want to check Leonid's question pages, different layouts and everything. Can you recommend some automated testing where one can be version of website without a similar manual testing will be hard. Okay, let's I'm going to come back to that towards the end of the session. I'm going to make a note of that now quickly. And just in the slides here. I'm going to put it right at the bottom of my learning outcomes. And we will get back to that towards the end. If anybody else has some ideas around that think about think about those those ideas. And we can chat about it later. Okay. Why do my slides keep jumping. So in my learning outcomes for today, we're going to just go through the process of configuring your local testing environment to test 6.3. And then I'm going to show you how I like to configure the WP debug log when I'm doing testing. Then I have a theme that I want to test I specifically want to test this theme in WordPress 6.3. And I'll explain why I want to and what process I go through. So we're going to test one or two new features coming to WordPress 6.3. So we're going to have a look at the dev notes. And we'll just test test one or two out to just kind of get a feel for for what's going on there. And that's kind of the goal today we're not going to be doing a massive deep dive into testing WordPress 6.3 or future versions of WordPress we just don't have the time for that. But I'll hopefully share some sort of experiences and hopefully those of you are here those of you are on the three or four scale. You can share some experiences there as well. The requirements needed to follow along today is to have a work with a local WordPress install to have a text editor, which allows you to edit the WP config file, and then a plug in or a theme to test I'll be using the sending theme. This is a theme that Emily who's in the chat. That's actually a good question so one would be lowest and five would be best if anybody wasn't sure about one to five. So one to five. Five being very good. We'll leave it like that. So in future future sessions I would have to remember that thank you Valerie for pointing that out. So the sending theme is a theme that Emily who is in the in the in the group here with us today has designed for me to work on and we're busy turning her designs into a block theme. So if you would like to install it and check it out you're welcome to from this link. I'm just going to pop it onto my desktop right now. And if you want to follow along with the development, you can go to the top level. GitHub repository which I will share with you here. And you'll see the worker do it. I also will point out is that while the theme we're working on is very cool and I agree there's actually a much bigger design that goes along with it we haven't even scratched the surface of what is possible. So I'm going to open up the Sigma file which Emily created for us if folks want to check that out. And if you're wondering I did in fact ask Emily, when we first started this whether this can be shared and she was happy to share this information so this is the theme we're working on. We've basically done the base layout, the fonts, and we've been working on the footer area. So you'll see that when we test it out in a second so that's what we're working on if you want to check out what we're doing there. A little plug, you can join us every Tuesday at 1pm UTC on my Twitch stream. Emily joins me and Aruba Ahmed joins me, and we kind of just figure out what we're doing as we go. It's a block theme we're busy designing, we'll have the live captioning just freaked out now. We will be releasing it to the theme repository once it's done, and it's kind of just a learning curve for all of us. Emily and I are learning about block theme development and Aruba is learning how to work with us. So that's all we're going to be testing today as part of our process of testing so you're welcome to download that and give it a try. All right, so let's get going. And the first thing that I want to share with you is this link. This is the sort of development cycle post. There's one for every single WordPress development release or WordPress release, should I say. And it contains all the relevant information. It contains links to all the dev chat agendas, all the summaries, the bug scrap schedules, all of the dev notes, the field guide, all post tags 6.3 and a link to the release each channel if you want to see what's going on there. And it also contains the list of the release team, the release schedule, and it's a great post to keep an eye on for what's going on and when things are coming out. And it's kind of the basis of what we're going to work off today. We are now here on the 27th of July so really as Tracy pointed out release candidate two has just shipped release or the release candidates are usually kind of most of the bugs are sorted out. WordPress is getting ready to be released and the final release will be released on the 8th of August, which is just over two weeks away. So we should have been testing this a little bit earlier, but it's a good good opportunity to test it now. And for those wondering about the early for East Coast US sessions I do also share the, the Twitch streams to my YouTube channel, which I'll share the link to with you in a second so you're welcome to catch up on those later if you would like to. All right. So, when I test. So let's look at two different types of testing, I usually do two different types of testing when I test a WordPress release. So I test it on a blank site. I make sure that the upgrade process works. I will start clicking buttons and doing various things. And I'll just see if I can find anything that is buggy. I usually try and do it as I say run about the early betas. I tend to focus on whatever I'm working on at the time. So if I'm building a plugin I'll test the plugin environments. I, I'm one person I don't have all the time in the world to test everything. But the more people that test different parts the more feedback that the WordPress call release team can get. And the more we can fix any bugs that get found. The way that I like to test is using the WordPress beta tester plugin. Pop that over there, pop it in the chat. This is a plugin that you can install on a local WordPress site that allows you to upgrade that site to whatever the latest and greatest version of WordPress is. So installing that site, installing that site, good grief, installing that plugin is simply a case of searching for the beta tester in your plugins list. So I'm going to open up a plugin list over here. And I'm going to click on add new. And then I'm going to search for beta tester. And it's usually the first one that comes up in the list. There it is. You can install it from here. And once it's installed and activated, then you can set your testing versions that you want to. There are other ways to upgrade your WordPress install to the latest release. I'm going to share a quick link with you here. So there's always this help test WordPress link. Post, should I say. There's again one for every, every release. And it contains a few ways that you can test where you can upgrade at least. The one is that you can upgrade using the plugin, which is here's the WordPress beta tester. And then there's this for more detailed steps you can click through. And you can get more detailed instructions and here's beta testing. And it talks about the plugin and then it also talks about, I'll share this in the chat quickly before I forget. It also talks about the fact that if you're using WPCI, you can use the WPCI command. WPCore update dash dash version equals trunk. And you can go to the latest version. So that's another way you can do it. I tend to prefer the plugin just because I find it a little bit easier to use the interface. The other thing I like about the plugin is it gives me some additional sort of options. So that's what I tend to use. I probably should use the WPCI version. But I tend to use the plugin. So once the plugin is installed, then you go into your. Under tools or settings kind of, which let me just refresh this year because I haven't activated the plugin yet. That's why that would be helpful. So let's activate that. There the plugin is activated. And that's under the tools. There is the beta testing option. So if you click on beta testing, you are presented with this beta tester settings page. And you have some options here. The first option is the point release. So this contains work that is occurring on a branch preparing for the 6.2.3 point release. So that's the stable code. That's not what we want to test today. What we want to test today is what's considered the bleeding edge. Now, bleeding edge is an interesting, interesting phrase, but it's kind of the bleeding edge of technology, if you will. And it's basically the trunk branch, which may be unstable. So it does say here in italics only use this if you really know what you're doing. In other words, don't do this on production sites. Leonid, I see your question there. We will get back to that as well. It's actually part of the session. So if we can put a put on that. So you click on bleeding edge, and then when you click on bleeding edge, you'll see at the bottom here, it gives you some options. So it's the latest daily updates, the beta or RCs only. So in other words, when the beta release comes out or when the release candidate release comes out, only update to those. Or you can select release candidates own. So my default is usually to switch on beta RC only because I as I mentioned earlier, I usually start testing at the beta stage. So when the first beta comes out, I'll enable the plug in on my test site. I will switch on bleeding edge and beta RC words on usually because I've saved it. And then I'll run the update. But how you do that is up to you entirely. But for now we'll select bleeding edge and we'll select beta RC only, and then we'll save changes. Once you do that, you'll see that the little message appears at the top of the screen to say, perhaps you should head on over and upgrade now. So from here you can click on that link. And that takes you to the WordPress update page or upgrade page where it will tell you that you're currently on version in my case I'm on 6.2.2. And it says an updated version of WordPress is available and here it says update to 6.3 RC to because I selected beta or RC to save this was still in the beta phase it would give me the beta option. You'll notice it does also say and it does give you a warning. Please back up your databases and databases database and files. So if you don't have a way to back up the site or if you if you don't care about backing up the site that's fine I never do because I'm testing locally. But if you are testing with a site that's important to you and you don't want to lose anything because things can go wrong while you're testing. Make sure you create a backup of some form or another. And then once you have once you have made that backup then you can run your upgrade. You'll notice that just below this goes back to Leonardo question earlier. Below there is an option to reinstall 6.2.2. So you can update to WordPress 6.3 RC to test out what you need to do and then roll back. Again, do this in a in a safe development or staging environment. Don't do it on production because things can go wrong. And what I mean by that is effectively what it's doing when you do this upgrade is it's downloading the latest release as a sub. Unzipping it over your WordPress core files and then you can test using those WordPress core files. If something goes wrong in that process, maybe the download fails or maybe the files get overwritten incorrectly. Maybe there's a hardware issue during testing which can happen. You're going to break your WordPress, your WordPress install. So make sure you've got a backup that you can restore from if you need to. But now I'm not worried about a backup. So I'm just going to hit update. And this will then go through the process of downloading the 6.3 RC to and installing it over my current 6.2.2 release. You'll notice it doesn't make any kind of backup for me. It doesn't sort of copy the 6.2 files anywhere. That might be a cool feature to have in the future for this plugin. But right now it just downloads. You'll notice that it can't check the authenticity. I think that's because this is a local site, but it unpacks the update and then stores the 6.3 RC to files onto my local WordPress install does take a few moments. So we're just going to wait for that to finish. But once it's done, we will be running the latest and greatest version of WordPress. And then we can start start updating things and start moving things around. Okay. So the first thing this this update does is it tells me there's a database upgrade required. This mail may not happen depending on what state your database is in. If there's a change to the database, there might be an update required. If there's options that have been removed, there might be an upgrade required. So I just let this update run. And once this is done, it should be good to go and we should be happy to continue testing. So there we are running WordPress 6.3 and we're ready to start testing things. Okay. Any questions on the beta tester plugin and how to install it and use it? If you do have a question, that's a great time to ask. Otherwise, we're going to move forward to how I like to test things while I grab a sip of water. All right. So the first thing that I like to do is I like to make sure that I've got my local WordPress installs debug mode on. And I do this because if there are any PHP errors that I don't see in the front end, then this will pick that up. So I open up whatever my code is that I'm using. I browse to the folder for the site that I'm working on. In this case, it is my learn press site, which is the one that I use for these workshops. And I was obviously doing some code here a while back. So I'm going to close all that down. And I open up the wp-config.php file that's sitting in the root of my WordPress install. It's the file that contains all of my database credentials. And I scroll down and you'll see I've actually enabled it over here. So I'm going to highlight this code. By default, this is what your wp-config will look like. No, not that. Let me roll back that here. So by default, this is what it will look like. wp-debate with constant. This is a PHP constant. All in uppercase will be set to false. What I like to do, and I will copy this code out and share it with you in the chat, is I like to set wp-debug to true so that enables debugging. I like to turn off debugging everything to the screen because I want to log it to a file. And I will enable the wp-debug log constant, which it logs it to a file. The other thing I do sometimes do is I sometimes create a custom debug log file. But in this case, it's fine. I'm going to use the default one, which is this debug log file over here, which is sitting in the root of the wp-content directory. And Beegat has quite nicely shared the debugging in WordPress article with us. So I don't have to go and find it and copy it and share it. So thank you Beegat for that. I'm going to delete this current debug log for now because I was testing something the other day and I don't need that. Because this setting will enable that for us. I'm going to copy this out if you want to set this up in your wp-debug config. Adrian's got it there already. And she says, yes, it's essentially the same as doing that. That's another way of doing it. So if it hasn't been defined elsewhere, you can enable this. There's multiple ways to kind of set that up. But that's basically what it is. So now when I'm testing my WordPress install, and I do this specifically if I'm working with either plugins or themes, any PHP errors that I might have missed, any changes in the way the PHP code works from the old version of WordPress to the new one will be logged to the debug log file. And I will pick them up while I'm testing. You could, if you wanted to, leave debug display set to true, and then you'll see it on screen. The only reason I don't do that is because sometimes seeing it on screen gets in the way of what I'm doing. But again, it's personally up to how you want to do things. You might prefer to see it on screen and then see what's going on first. It's just down to personal preference. So I usually leave that as false. And then what I'll typically do is I'll start testing my product first. So if I'm testing WordPress 6.3 for the purposes of testing 6.3 for bugs and things like that, I'll test WordPress 6.3 first. But usually I start with whatever products I'm working on. So if it's a plugin or a theme, I'll start by testing that plugin. And this gets back to the question. And I want to actually touch on that question in a second. Now, this gets back to the question that Leon had about when everything is broken, it's easy to spot. But what if only a few things are broken? Can you recommend some automated testing which can compare one version of a website with another or similar? And this is actually a perfect opportunity to talk a bit about automated testing. This wasn't part of my prepared session today, but this is a good time to talk about. Laura says, I can't find the config file. The config file is in the root of your WordPress install. So if you open up your WordPress install, you should see a file, something like index.php. You should also see a license.txt file. And then towards the bottom of that will be a wp-config.php file. If you don't have a wp-config.php, that might be because you haven't set up that WordPress install yet or because you're on a hosted environment. So it's just in the root of the... So it's not in admin or content or includes, it's just in the root of the WordPress install, Laura. If you're not finding it, let us know and we'll help you find it there. But it should just be in the main install of the WordPress site. If you're working on a hosted environment, it might be in a different spot. But by default, it's usually just in the main WordPress install. Let us know if you don't find it, and we'll dive a bit deeper there. But while you're looking for that, I want to get back to the automated testing. So when it comes to automated testing, there are two types of automated tests that you can create. The one is PHP-based automated testing, and you would use something called PHP Unit for that. So PHP Unit is a framework for testing your PHP code. And you basically write PHP code to test your functions and your classes and all of those things. I am planning a session on PHP Unit down the line. We'll probably look at testing a plugin with PHP Unit. But that's one way you can run automated tests for specifically plugin code or any kind of custom theme code functions like PHP and that kind of thing. When it comes to front-end testing, you don't have things like PHP Unit to be able to use. So you can use what is known as end-to-end tests. And that in itself is another workshop or another course or another series of tools or all on its own. But WordPress users, I just want to do a quick search for the framework for WordPress users. I'm going to see if I can find it here. Here we go, the WordPress ETE test. It's called end-to-end testing. And you'll see it says, the purpose of ETE or end-to-end testing is to simulate the real user scenario and validate the different flows. So typically the way ETE testing works is you will have a page that has some information on it. And you can then test whether specific elements appear on the page, specific headers, specific paragraphs, specific divs with class names and all that kind of thing. You can also test form flows. So you can test filling in a form. Depending on how the ETE testing works, it's usually either some JavaScript code that runs and physically works with the page or it might be some, what's known as like a ghost browser instance that runs and then the JavaScript runs on that. I will share those links in a second with you, Mark. But you can use these tests to do it. Now, there are different front-end testing frameworks that you can use. I think Jest is one. Jest is one option you can use. I will share all these links in a second. Another one that I recommend looking into is, I can't think of what it's called now. So give me a second while I search for it through what I remember it. There's a testing framework called Codeception, which is mainly for PHP frameworks. But then there's also a WordPress version of this, which I'm going to find for you here. Here we go. Oh, there we go. It's called WP Browser. Now, I had the lovely opportunity to meet the developer of WP Browser, Luca Tume. He built this based on this Codeception thing. And basically it allows you to create what's known as acceptance functional integration tests for WordPress plugins, themes, and whole sites using Codeception. And this uses a similar sort of, you basically run PHP code. And you can do things like, so here's an example. You can log in as editor with the password secret. Then you can check here on a certain page and you can check that you see certain things. It does require a bit of setting up and a bit of understanding how this testing stuff works. But it's one of my favorite ways of testing plugins. I'm going to use this for the series of simple podcasts and plugins for testing certain flows. Just as another one, as I mentioned, this one is specifically JavaScript based. But there's a couple that you can use to set up your testing. So I'm going to copy. I see Birgit's already added the PHP unit and the WP Browser links. I'm going to add the Jest link as well. So I recommend checking those out. I will be doing some workshops on how these things work at a later date. We unfortunately don't have any time to dive into that now, but it is great too. And you can use either Jest or you should be able to use WP Browser to test your pages on your site. So what you would do is you would set up your site. Then you would set up all your tests. Then you can update to 6.3 and then run those tests. And if everything passes, you know nothing's broken. So those are some options and some ideas out there of how you can do both back end and front end testing instead of doing it the manual method. Okay. I hope that gives you, Leonid, I think it was. I hope that gives you some information there. You said there, I thought more about something for website owners or a few software in the market, which can stick screenshots of some pages and compare them between versions, but that doesn't work with the whole website and if you keep pages, I've never used, I've heard about those software packages because I'm a coder. I tend to use stuff that requires writing code. So that's just my personal experience. If anybody else has examples or experience with those tools that use screenshots, please do share that in the chat or you can chat about it if you will. But I tend to use these other tools mainly because I'm a developer, I write code, so you look for tools that allow me to write code and do my testing that way. So hopefully this will give you something to dive into and to work with. All right. I'm going to close some of these things down. Okay. That's the beta tester. All right. So typically what I'll do when I'm testing a new version of WordPress is I'll have the theme or plugin that I'm testing on and I'll have a list of the things that I'm testing for. Depending on how far I am with the developer to the product, I might have a bunch of unit tests that I will run at the time. But if I'm just starting out like I am now with sending, I'll have maybe one or two things that I'll be looking at to make sure that they work. So to give you an example, if you have a look at the Figma file that I shared with you earlier, we've been working on the footer area in the theme. So the footer area has this horizontal rule that runs from the end of the sort of content area at an angle. It's quite thick and it runs off the screen. And so that's as far as we've got with the styling. So all I'm going to do now is I'm going to make sure that still works and does what it should be doing. So I'm going to open up my WordPress test site. This is sort of where I'm building this ending theme. You'll see the design here in front of me. It's using the same font. And if I scroll down to the bottom, I'll show you what it looks like on this site. This is running 6.2. Quite a few posts. So there we go. So there is the horizontal rule. It is in line with the WordPress text on the side here. You'll see that the line is quite straight and then it's quite thick and then it runs off the screen. So now I want to test that on my test site. So obviously I'll need to install that theme. So let's do that very quickly. Let me just zoom window gets in my way. So I'm going to upload this theme from my desktop and install it. And then I'm going to activate it. And now if I switch to the front end of my site, the first thing I'm going to do is I'm going to check that. And you can see already that the font size looks good. If I compare it to my other site, it does look like things are working the way I expect them to. And if I scroll all the way down to the footer, there we go. So it does look like it's doing what it needs to do. It does look like it's nice and quite thick. It's going off screen. That's great. So that's one way you can manually test when you're working on something to make sure everything works. The other thing I want to do as well is I want to make sure that it looks like it does when I'm working in the site editor. So if I click on edit site, now I'm seeing everything is quite different. And Emily will also probably agree with me that things are a lot different now with the 6.3 release. So there's some new things down in the right here. So that's great. He said now I'm running the latest version. But if I edit this, I want to be able to scroll down and edit my footer. Make sure that I was what I was working on works. So if I click on that, that takes me to the footer. That's great. If I click on the horizontal rule, the last thing we did was we were busy adding some custom tool by elements to the horizontal rule. So if I click on this, there is the click here button. Emily, I remember we were working on that last week. So it does look like that functionality is working as well. And so typically what I'm doing when I'm working through a custom development project is once I've ran all the automated tests, I will then have a few manual tests that I'll do. And the reason I like to have a few manual tests is because sometimes you just want to have a feel for what's going on. You want to make sure things are working the way the user would see them. I will typically, if it's a plugin, I will have a list of the most important user flows that a user might go through. So for example, when I was working at serious simple podcasting, our user flow was the user needs to create an episode. The user needs to create a new podcast. Certain things the user needs to be able to do. The user needs to install the plugin and go through the user onboarding. So we used to have automated tests with that, but then we used to manually test it as well. Just to make sure that while the automated tests are good, automated tests might not be 100% perfect. For example, you might have a situation where you've got a header with certain text and you can write your automated tests to say, I see this header with this text, but it might be slightly off and you haven't written the automated tests for that or it might be displaying slightly differently. So it's always good to do a manual test as well and just make sure everything works the way you need to. Once I've ran all those tests, I will then switch back and check if anything has been logged to the debug log. And as I mentioned earlier, if I have set this WP debug log constant to true, it'll create a debug log file in the WP content directory. And as you can see here, that file doesn't exist. So that tells us that no errors have been reported, which is great. So I've tested my functionality using my automated tests. Then I test using a manual process and then I check for any debug log issues. In this case, everything seems fine. So once I do that, then I move on to testing some new 6.3 features. And I do this because I like to help the folks test 6.3. So I like to try and give some of that testing time back to the development process. And so the first thing that I will do is I will go to the development cycle page. It's one I shared earlier. And I will click on there are usually dev notes. And there's a few dev notes usually. So I'll click on dev notes. And I'm going to copy that link into the chat as well. And then I'll just kind of read through the dev notes. And I'll see if there are some interesting things that have been fixed that I might like to test. And the one I saw earlier when I was preparing, that's why I was a little bit late getting started, was that there are now required attributes to the username and password fields, which I thought was a cool thing to check. And one of the reason I like this is if we click on this track ticket, I'm going to share it with you in the chat if you want to open it up, is this was created eight years ago. So for those of you who don't know, there are a number of WordPress tickets that have been around for a while. And depending on what is a priority at the time, some will get fixed quicker than others. But this one has been around for eight years, and they've gotten around to fixing it in the latest release. So I think this is a cool one to test, verify that it's working, and if it isn't, send an update through. So what I will then do is I will read about the notes. So here it says it adds a required attributes. So I'm guessing what that means if we try and submit the form, it's going to pop up that little HTML required on the form fields. So then I'm going to test that out manually. So in this case, all that requires me to do is to log out of my WordPress instance, which I'm going to do right here. So this is not the one that I'm testing on. So I'm going to close that down. This is the one that I'm testing on. So let's exit out of here. And then I'm going to log out. There we go. And now I'm here. This is the login form. And I'm just going to hit the login button because I'm expecting to see the required little pop-up happen. And I'm interested to see what happens when we do that. And there we go. Here's the little please fill in this field pop-up. This item to show is my one password. So I'm going to disable one password right now. I don't know if I can actually do that right here. So I'm going to remove that. Wait. That's not what I want. Let us, when I click on the extension, so that won't come up. OK. Let's reload that. So now let's try it again. So here we go. Let's click login. There we go. Please fill in that field. So that little pop-up happens because the required attribute is on that field. So now I know that's working. So if I type in my username and I hit login again, there it's popping up for the password field. So I'm happy that that's working the way I expected to work. And that's really cool because now it's a little bit more accessible. It's easier for people to see that the password field is required. My understanding is that those fields will also then trigger screen readers to have the same message. So that's a really cool addition to 6.3. OK. So now I've checked that out and I'm happy that that's working. So then I'll go through the dev notes further and I'll look for. And what I also tend to do is I look for ones that are interesting to me to test. So in this case, it was interesting because it was eight years old. Maybe it's interesting because it's something I might want to work with in the future. But I'll just scroll through all these dev notes and I'll look for things that I want to test. If I find the issue to still be existing or still be a bit weird, then I'll log. Then I'll either go go to the track ticket for it and I'll log some further information there. If I find a new issue, then I might create a new track ticket. So if you've never heard of what of something called track. It's this year all over here. And it's basically the place where all issues or bugs related to WordPress call get locked. You will need a WordPress.org account to be able to log any track tickets. But it's where you go to log any bugs that you might find. Now there is a slight caveat to that. If your issue is specifically related to the site editor, the block editor, basically anything that falls under the Gutenberg project, then the recommendation is to log it in the Gutenberg issue tracker, which is on GitHub at this URL, which I'm going to just get the issues list here. So there we go over here. What I can say, Valerie, I did see your question. I'll get back to that in a second. What I can say is that if you do log the issue in track, and it's actually meant to be logged in Gutenberg, the folks are very good at triaging the issue and then saying, look, we're going to log this as an upstream issue within the Gutenberg project. But if you're busy doing testing on any of the betas or any of the release cycle releases, and it's specific to either the site editor, or you're working with the block editor in the post or the pages, then it's usually better to look for it here or see if you can log it here. Logging it in the Gutenberg issue list requires a GitHub account. So if you don't know how to do that, there are resources that you can read to help you get that set up. And then once you've got that set up, you can log in to Gutenberg. For both environments, for both logging issues in GitHub and logging issues in track, it's a good idea to search for whether your issue already exists. Because if you can find the already existing issue, then you can add your information to it, and it doesn't create multiple places for folks to look for. That having been said, again, the core teams, the bug triage teams are very good at saying, oh, this is related to another bug, and either closing it or linking it or whatever the case may be. If you have an existing one and you're struggling to search, you shouldn't log the issue. My opinion is rather log it and let someone else tell you there's duplicate than don't log it at all. OK. Valerie says, which plugin, which beta plugin tester is best? I assume you mean the beta tester plugin that I installed here. There is only that one that I'm aware of. There might be others, but this is the sort of official one. The WordPress beta tester plugin, if that's what your question was about, this is the official one. So that's the one that I use. If you meant of what is the best option between using this plugin or WPCLI, as I say, for me personally, I prefer this one because you could roll back quite easily. You can roll back using WPCLI, but I just like the user interface of the WordPress beta tester. I hope that answers that question there, Valerie. Well, we're here. Let's chat about that. So once I've done my testing and I've logged any issues I want to log or I've figured out whatever I need to do, now I want to roll back the site to 6.2. Oh, where is the link? That was the question. Let me just do this. I think someone did share it earlier, but let me find it quickly. Here we go. So I'm going to copy it from there and pop it over there. So there's the link for that. So now that I've done all my testing, now I want to roll back. So using the same beta tester settings, I can go into the beta testing option under tools and then I can then either from here I can switch it back to point release and it'll then update to point release or I can switch to any other of the nightlies if I want to or whatever the case may be. So typically what I do is I switch it back to point release. So this will be 6.2.3 for example. And then I'll let that update run. The alternative option is you can just go from this page. You'll see it says by default your WordPress installation uses the stable update channel. So return to this, please deactivate the plugin and reinstall from the WordPress updates page. Now there's a few ways you can get to the WordPress updates page. The one way is from this plugin settings page. So if I click on here, it takes me straight to that page and then from here I can reinstall 6.2.2 which is the one I had installed originally or if you go into your dashboard menu you'll see that updates is an option under dashboard. So let's say I was on plugins and I want to, let's say I'll deactivate this plugin and I forget to do the updates back to 6.2.2. So I've deactivated that if I go to dashboard and I go to updates, it takes me to that same updates page. So I don't need the plugin to roll back. I can just use default call WordPress functionality so you'll see here it says update to the latest 6.3 nightly. I don't want that. I want to reinstall 6.2.2. Again, it says backup your database and files. If you want to, you really should at this point because you've made a bunch of changes. I'm not going to worry because this is a test site. So I'm simply going to go reinstall 6.2.2 and it will then go through the process of downloading those files. You'll see it downloads 6.2, no contents up. It'll verify if it needs to. Again, it can't verify probably because I'm local. Unpack the updates and override those files over the profiles. And so once this process is finished, I should be back to 6.2.2 and then I can carry on doing whatever I wanted to do. As we mentioned earlier, if you're going to do this, it is highly recommended that you don't do this on any kind of production environments, any kind of live sites that are important to you. Do it on local sites. Do it on staging sites. If you're hosting a company, offers you a staging site option. So here it's asking me to update the database again. Obviously, there's a change between the two. So I'm going to run that. And there we go. I'm back on 6.2.2. So now I can just carry on using the site for whatever I need to do with it. Okay. And that is my typical process for testing. So I will install the beta tester. I will enable debugging. And then I will start testing my plugin or my theme. Another good reason to test your plugin or theme is so you can make sure you're ready for 6.3. And if there's any updates you need to make, you can make those updates. Once I've done that, then I'll test 6.3 itself. And I'll usually spend, what I like to try and do is spend the equal amount of time that I spent testing the plugin or the theme as I did testing WordPress 6.3. My specific scenario is that I'm usually, well, I was before I became a developer educator. I was usually working on a single product or site at the time that 6.3 version is coming out. So I would use that as my test bit. So if it was a site that I was working on for a client, I was usually working in the theme. So I would use that local version of the site and that theme to do my testing. When I was working at Castos, I was primarily working on a plugin. So I would use that plugin and I would do my testing on that. So I don't think it's necessary for everybody to test with every type of product and every type of version. I think that the more folks we can get testing on whatever they're working on at the time, the more input we get from people around the world. If every single person, for example, in this workshop spent half an hour testing their product, their plugin, their theme, or the site they're working on in 6.3, and then another half an hour just testing 6.3, we would have, let me look at the moment, we've got 17 people in the workshop. We'd have 17 hours worth of testing happening. That would be 17 hours more than what's already happening. So I do recommend doing some testing for yourself if you want to. The other advantage of testing early is you can see what's coming. You can go and read the dev notes. You can go and see what's happening in the new version of the release. You can comment on what's going on. And it just gives you more input of what's happening and what's coming in the future. Okay. So Linda says, thank you for covering this. If we test, should we report what we've tested? So you don't have to report what you've tested if you've tested things. The only time you need to report something is to find an issue. Now I'm going to give you an example. I saw this the other day and I hope it's still there. And if it is there, I'm planning on logging this. So let me show you what I mean. Let me quickly upgrade my learn press again. I'm going to enable the plugin and see if I can, see if I can get it to happen again. They might have fixed it. I kind of hope they haven't. So let me update to that version quickly. Okay. You see it's already on beta RSE only. So that's great. Upgrade to 6.3. 6.3 RC2. So let's do that. So the issue that I found was when I was clicking through the pages and the templates in the site editor, I noticed that if I clicked on, I think it was the index page. Then it took me to the index, to edit the index template. But then when I click back, it showed me the list of templates instead of the list of pages. And I found that confusing. And I meant to log it at the time, but I forgot to. So I want to see if it happens again. And if it happens again, I'm going to log it. And then I'm going to show you kind of what I would do to log, to log this issue. So let's quickly, let's quickly go through the updates. Oh, Laura was having the same issue. Okay. So it does sound like it's something that is an existing issue. So that's great that somebody else had the same problem. It wasn't just me. Okay. So let's do the update. Let's go back to here. So let me go into the site editor. So I seem to recall it was when I click on the list of pages on the left hand side here. And then I click on the index page. Now my brain is saying I'm editing the index page. But what I'm actually probably editing is the index template, which makes sense. But now when I click back, okay, so it was going to the list of templates originally. It now seems to have been fixed, which is great. I'm going to just make sure of that. So let's go and edit this. Let's make a quick change to this page. So I'm going to move that up. I'm going to save this. So that's now saving the template. So let's go back. Okay. So I'm back to the English. Now this, remember this I click through from pages. I see. So it goes back to the list of templates. Now, Laura says, but why was it under pages? So that's interesting because we do have an index page. And an index template. Or do we? Let me check this. So let me see here in my pages list. I don't have an index page. So there is a little bit of confusion there. And I do feel like that's a bit of a back. So under pages, I should just have privacy policy and sample page, but I've got an index page. And that's actually the home page, which is the thing that you set. And I think it's reading. You can set your homepage displays your latest posts. So that's kind of why the index page is under the list of pages. So I do kind of understand that. But what I would expect to do is once I've clicked on index, and once I've edited it, so let's move the image back down and saved here. And I go back. Now we'd expect this to go back to the list of pages, but it goes to the list of templates. So that's a little bit of a user to me. That's a little bit of a user design user interface design, maybe not an issue, but it's not 100% clear because if you were a user who didn't expect to go back to templates at this point and you saw this, you might get confused. Emily says it looks like it's using the same template icon. Yes, that's correct. Laura says try adding an index page and repeat the steps and see if you still go to templates. Well, that's interesting. So let's do that. Let's add a page called index. And let's publish that. And then let's go back to the editor and let's go back to the pages. So now we've got two indexes. So that's the page index. And this is not the index page. This is the index template, but it works as the index page because that's where I've set things. So let's do this. Let's go back to the settings. And let's change this to a static page and let's call it the index page and let's see what happens there. So now if I go to the editor and I go to pages, see now that index page is gone. The second index page, the one that's the actual page, but I want to see what happens if I click on index. That takes me to the index page because I've set the change. And that's where I think the confusion is happening for me. And when I haven't set an index page or a home page, it shows me index in that list, which is actually the template, which is not wrong because that is the template that loads when a home page hasn't been set. So yeah, a little bit of a user interface concern, not 100% clear what it's doing. So here's where I might log this as a question or as an issue or whatever the case may be. So what I would typically do now, is in the editor, I would go to the Gutenberg issue tracker on GitHub. And the first thing I'll do is I'll search for something like index page and see if there's already something around this. So I don't see anything here. Then I might do something like index template. Maybe somebody's logged something about index template. That doesn't seem to be the case. Yeah. So it doesn't look like this. And I would expect it to be pretty high up if it did exist. So there doesn't seem to be anything logged around this. So this is probably a good issue to log. And maybe I'll get some feedback and folks will just say, yes, maybe that's the way it's meant to be. Maybe there is a possibility we can improve the user experience. Maybe we'll do that in the future release, which I'm fine with, you know, if it gets improved as we go along. But I do feel like this would be a good thing to log. So then I'll click on new issue. And I'll run through and I'll check, well, which one of these is this? Is it a bug report? Is it a feature request? Is it a general help request? It's not one of those two. It's probably a bug report. Our click gets started. And then I'll start listing out what I expected to see. This is not this. We don't have time to dive into this, but I would then log something along the lines of when my site is set to show the list of posts as the homepage. Then it shows it as the index page. When I click through and come back, it shows the list of templates on the list of pages. This is a bit confusing. Then I'll add when I change it, when I create an actual homepage, then it shows the list of home pages, but sorry, the list of pages. But then again, when I come back and shows the list of templates and I'll add screenshots of the process, maybe even a video of the process, but that's where I'll log everything there. If anybody would like to log that, you're more than welcome to, but that is something that I noticed. I just thought it was interesting to share how I would do that process. Okay. Right. That is my bit for today. Does anybody have any questions around this process of testing? Any other ideas or suggestions or comments that you might have? Maybe some experiences you've had with testing? Hopefully this has inspired you to do some testing before 6.3 is released. If nothing else, if you don't test it for your own sites, if you don't test it for your plugins or themes, just testing it to know what's coming is also a great thing to do. Spending half an hour testing the 6.3 release so that you know what's coming so you get used to any new features or functionality is a great thing to do. Does anybody have any other questions before we wrap up for the day? All right. It doesn't look like anybody has any questions. Thank you for joining me today. I hope this has been useful. I do plan on running this session again for 6.4, 6.5 and all future releases. Hopefully we'll have some more interesting bugs and issues next time. What I'd like to try and do maybe for a future one is actually do some automated tests and set those up. We'll do that hopefully before then. But thank you all for joining me. It was lovely to see new faces, old faces, old faces who are here all the time. And folks that I know it's always great to chat and interact with everybody. Next week, I might do something different. I've been thinking about something different that I want to do. So we'll see how that goes. But I'm kind of familiar, not old. Yes, thank you, Linda. That's a much better way of saying it. Familiar faces, thank you. I apologize for that old comment. Familiar faces. So I hope you've enjoyed today's session. And next week, as I say, I'm still deciding what I'm going to do there. But I'll probably figure that out tomorrow and I'll post it by the end of the day tomorrow. Thank you all for joining me. It was lovely to interact with you all. And I'll see you all next week. Bye.