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 my 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 trip myself, 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
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 Ozm
who's 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
'cause I was bouncing all over the place,
but hopefully 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 long distances.
Brutal."
Yes, I had no idea.
I'm learning how brutal it can be.
So it's quite a thing.
We got Ger, got 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 where we were for the week last week. Jean from New Jersey. Hi, Jean.
Rabam from India, hi there.
Monsignor from Orlando, Florida, welcome.
I'm just gonna make a change there.
Creative, Linda says hi from Virginia.
Linda says, "Actually, Linda, not sure.
"I got signed up through the snow."
Don't worry, I do things like that all the time with Zoom.
Zoom is a weird piece sometimes.
Bigger 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, then back to winter.
And it's such a weird feeling landing in Cape Town.
It'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 it 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 was very warm outside of the world.
All right, 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.
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, when this goes live. Okay so today we are going
to be looking at testing WordPress 6.3. I know that Courtney did 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
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.
There we go, we're even later than I thought.
Normally I like to start testing during the beta phase.
Please 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 re-initialize 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.
Leonid, I see your question,
I'll get to that in a second.
You are welcome to ask questions as Leonid 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.
I do tend to 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/news.
It's a new developer blog that was released a few months ago.
And there are always some interesting things
going on over there.
Lian, in terms of your question there,
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
making sure that you've tested it and it works first and they're not creating 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 or 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 whenever I have to update my Microsoft installs, my Windows installs,
I always expect things to go wrong. So A, try it on the development side first, and B,
have a rollback process. So have a backup setup, a copy of the site setup so that you can
You can roll back if you need to.
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 roll back
once we'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 I will, 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.
Birgert says there, "For testing purposes, there's helpful testing from older versions
and development sites like real sites, or maybe if skipped previous versions."
There's a perfect example.
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 answered, before we get going, on a scale of one to 10, and Leona, that's
your question there, so we'll get back to that in a second.
On a scale of 1 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 1 to 5,
where do you fit in?
I am personally, I consider myself a 4 because I always believe there's always something
new I can learn and I always do learn something new whenever I'm doing things.
I consider myself a 4.
Adrienne says she's a 1.
Laura says she's a 3.
Emily says she's a 0.
Emily, are you sure about that?
Leonid says a three, Begget's four, Gina's three,
Sabam's two, John says two, Andrew says two,
Adrian says zero, and Mark says two.
Okay, so we've got some folks who have done this before,
they've got some ideas.
That's great, 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 get out of this.
I just want to check Leonid's question,
pages, different layouts, and everything,
and everything, especially there.
Can you recommend some automated testing?
Where one can be a version of website
with another similar?
Manual testing will be hard.
Okay, I'm gonna come back to that
towards the end of the session, Leonid.
I'm gonna make a note of that now quickly,
just in the slides here.
I'm gonna 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,
about those ideas and we can chat about it later. Okay, why do my slides keep jumping?
So our 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. And then we'll test one or two new features coming to WordPress 6.3. So we'll
go and have a look at the Dev Notes and we'll just test one or two out and just kind of get a feel
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 on the three or four scale, you can share some experiences there as well.
The only requirements needed to follow along today is to have a local WordPress install,
to have a text editor, which allows you to edit the wp-config file,
and then a plugin 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. Let's actually make a
point of that. 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 same thing 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 work we're doing. What 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 Figma 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.
So it's a block theme we're busy designing.
will be, will, will, 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 Rube 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
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 bike scrub schedules,
all of the dev notes, the field guide, all post tags 6.3,
and a link to the release leads 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.
So we are now here on the 27th of July.
So as Tracy pointed out,
release candidate two has just shipped.
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 opportunity to test it now.
For those wondering about the early East Coast US sessions,
I do also share 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.
I test the release itself.
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,
that 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'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
core 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.
It's usually the first one that comes up in the list.
There it is. You can install it from here.
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.
There's always this help test WordPress link,
a post, should I say.
There's again one for every release.
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 correctly before I forget.
It also talks about the fact that if you're using WP CLI,
you can use the WP CLI command, wp-core update dash dash
version equals trunk, so that'll update 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 WPCLI version,
but I tend to use the plugin.
So once the plugin is installed,
then you go into your, I think it's under Tools,
or Settings, can't remember which,
let me just refresh this here because,
oh, 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 then it'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 is 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 phrase
but it's got 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 as I mentioned earlier, I usually start testing
at the beta stage.
So when the first beta comes out,
I'll enable the plugin on my test site.
I will switch on bleeding edge and beta RC,
or it's 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 the 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 RC2,
'cause I selected beta or RC2.
So if 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 backup your databases and files.
So if you don't have a way to backup this site,
or 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 made that backup,
then you can run your upgrade.
You'll notice that just below,
and this goes back to Leonard your question earlier,
below there is an option to reinstall 6.2.2.
So you can update to WordPress 6.3 RC2,
test out what you need to do and then roll back.
Again, do this in a safe development or staging environment.
Don't do it on production 'cause 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 zip,
unzipping it over your WordPress call files,
and then you can test using those WordPress call 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 gonna 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 gonna hit update.
And this will then go through the process
of downloading the 6.3 RC2
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.
It 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 unpacks the update and then installs the 6.3 RC2 files
onto my local WordPress install.
Does take a few moments.
So we're just gonna 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 updating things
and start moving things around.
Okay, so the first thing this update does
is it tells me there's a database upgrade required.
This may or 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, we're 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 gonna 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 LearnPress 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 gonna 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 gonna 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 would look like.
WP debug 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 concept
which 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.
We'll just use the default one,
which is this debug log file over here,
which is sitting in the root of the WP content directory.
And Beagut has quite nicely shared
the debugging in WordPress article with us.
So I don't have to go and find it, copy it and share it.
So thank you for being good 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 gonna copy this out if you wanna set this up
in your WP debug config.
Adrienne'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 it.
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 other plugins or themes,
any PHP errors that I might've 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 product 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 wanna actually touch on that question in a second.
Now, this gets back to the question that Leonid 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 roots of the website.
It's not in admin or content or includes,
it's just in the roots 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 wanna 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 a 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, you write PHP code
to test your functions and your classes and all of those things.
I am planning a session on PHPUnit down the line.
We'll probably look at testing a plugin with PHPUnit,
but that's one way you can run automated tests
for specifically plugin code or any kind of custom theme code,
functions of PHP and that kind of thing.
When it comes to front-end testing,
you don't have things like PHPUnit 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 tutorials all on its own.
But WordPress users-- I just want
to do a quick search for the framework that WordPress users.
See if I can find it here.
Here we go, the WordPress E2E test.
It's called end-to-end testing.
And you'll see here it says, the purpose of E2E
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 just as one,
just as 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,
basically you 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 you're on a certain page
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 used to use this for the Seriously Simple podcast
and plugin for testing certain flows.
Jest is 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 gonna copy.
I see Birgert's already added the PHP units
and the WP browser links,
I'm gonna 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 could 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 backend and frontend testing
instead of doing it the manual method.
Okay.
I hope that gives you a learned, I think it was.
I hope that gives you some information there.
You said there, I thought more about something
a website owner saw a few software in the market
which can stick screenshots of some pages
and compare them to inversions,
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 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 gonna 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 gonna do now is I'm gonna make sure
that 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 wanna 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, this 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 gonna do is I'm gonna 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.
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.
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.
If I click on Edit Site,
now I'm seeing everything is quite different.
Emily will also probably agree with me that things are a lot different now with the 6.3 release.
There's some new things down on the right here, so that's great.
At least I'm now running the latest version.
But if I edit this,
I want to be able to scroll down and edit my footer,
make sure that what I was working on works.
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 toolbar elements to the horizontal rule.
If I click on this, there is the Click Here button.
Emily, right in the middle, 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
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,
the 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 and say,
"I see this header with this text,"
but it might be slightly off and you haven't written the automated test 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 gonna 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,
and 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 gonna share it with you in the chat
if you wanna 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 note.
So here it says it adds the required attributes.
So I'm guessing what that means
if we try and submit the form,
it's gonna 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.
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. Okay, let's reload that. So now let's try it again. So here we go. If I 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 expect it
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 fields are 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.
Okay, 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 ages 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 nodes
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 either 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 something called track,
it's this URL over here.
And it's basically the place where all issues or bugs
related to WordPress call get logged.
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 the CRL, 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
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 that issue.
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. So don't feel like if you can't find 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
this duplicate, then don't log it at all. Okay. Valerie says which beta plugin tester is best.
I assume you mean the beta tester plugin that I installed here. There is only that one that
that I'm aware of. There might be others, but this is the sort of official one, the
WordPress BaterTester 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 BaterTester. I hope that answers that question there, Valerie.
While we're here, let's chat about that.
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 this side to 6.2.
Oh, where is the link?
That was the question.
Let me just do this, I think.
I think someone did share it earlier, but let me find it quickly.
Here we go.
I'm going to copy it from there and pop it over there.
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.
Typically, what I do is I switch it back to point release.
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.
To 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 update back to 6.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 back up 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 content zip.
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.
See 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 was coming out.
So I would use that as my test bed.
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
in 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 if you find an issue.
Now I'm gonna 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 LearnPress again.
I'm going to enable the plugin
and see if I can get it to happen again.
They might've 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 RC only, so that's great.
And let's go upgrade to 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 this issue.
So 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.
OK, so let's do the update.
And let's get 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, it--
OK, 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.
OK, so I'm back to the inglets.
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 templates. 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 bug. 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 home page 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 it to do is once I've clicked on index, and once I've edited
So let's move the image back down and save it 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,
then repeat the steps and see if you still go to templates."
Well, that's interesting. 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.
Now we've got two indexes.
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.
So 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,
because this 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.
there is a possibility we can improve the user experience.
Maybe we'll do that in the future release, which I'm fine with.
If it gets improved as we go along.
But I do feel like this would be a good thing to look.
So then I will 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.
I'll click Get Started, and then I'll start listing out what I expected to see.
This is not, we don't have time to dive into this, but I would then log something along the lines of
when my sites are 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 of 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 pages, but then again, when I come back, it 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.
So if anybody would like to log that, you're more than welcome to.
But that is something that I noticed,
and 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, and old faces, 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'll be 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 for many of 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 day tomorrow.
Thank you all for joining me.
Lovely to interact with you all.
And I'll see you all next week.
Bye.
[ Professor