[BLANK_AUDIO]
All right, I forgot to do something.
[BLANK_AUDIO]
I have a little do not disturb sign that I forget to switch over otherwise people come barging in.
[LAUGH]
Good morning from the US, good afternoon from South Africa.
It is live stream time.
I'm just gonna pop on over to the meetup and just focus on that we are live.
[BLANK_AUDIO]
The link don't I?
[LAUGH]
There we go.
[BLANK_AUDIO]
Let's pop that in there.
[BLANK_AUDIO]
Why can't I see the comments?
[BLANK_AUDIO]
I'm not even logged in.
How weird.
[BLANK_AUDIO]
It's logged in quickly.
[BLANK_AUDIO]
Let's try that again.
[BLANK_AUDIO]
Hopefully you can hear me.
If you can't hear me, let me know.
[BLANK_AUDIO]
I should have everything should still be working from last time I did this, but it's been two weeks since I last did this.
So if you can't hear me, if the music is too loud, whatever the case may be, let me know.
[BLANK_AUDIO]
All right, so we are continuing along with learning how to contribute to WordPress.
If you missed the first session on how to set up the local development environment, you can get it from this URL.
This is the recording of the last session.
[BLANK_AUDIO]
So if you want to know how everything is set up, you can follow that.
I'm going to just turn this music down a little bit.
[BLANK_AUDIO]
There we go.
And today, well, last week I was planning on looking for some issues to work on, and then I had to cancel the live stream at the last minute.
So today that's what I'm going to start doing.
I'm going to start looking for some interesting issues to work on.
I'm going to share where you can find all of those issues.
And then hopefully we can find something that I feel comfortable working on as a good first bug.
So let's dive in.
The first place to look for open issues to work on in the WordPress project is at make.wordpress.org/core.
Pop that in the chat.
Oh, I should mention I'm using a new keyboard today.
I'm going to share a picture of a keyboard, Microsoft Sculpt ergonomic thing.
It's taken me a while to get used to it.
So if my typing is a bit more wonky than usual, I apologize.
I will do my best not to make too many mistakes.
I'm also just going to turn off my phone, or at least silence my phone.
It is already silenced.
Okay, excellent.
All right, so make.wordpress.org/core.
That is the core WordPress or the WordPress core team, if you will.
It's their site.
It's their blog.
It's where they post updates.
It's where discussions happen.
It's where you can find the handbook.
So that's this link over here, handbook.
It's also where you can find the tickets that folks are working on and the different components.
So if you click on components, you can scroll down.
You can find all the different components.
And for my purposes, I'm going to be focusing on the REST API.
So you'll see there is the REST API there.
These are the folks who are the maintainers.
I think they call them maintainers.
That's correct.
Of this component.
So it is Timothy Jacobs and Ryan McHugh and Rachel Baker,
Kanim White, or Katom, I think I pronounced that,
and Jonathan Harris, who I had the pleasure of meeting in Europe.
Where it came from, Europe and Athens.
And so if you click on that, then it takes you to the component page for the REST API.
Currently, Ryan McHugh is the tech lead.
Katom White is the design lead.
Features can be tracked on the Trello board.
Meetings are held every Thursday at 8 AM my time in the evening, 8 PM my time in the evening.
So that would be around about 6 PM UTC, I think it is.
They also manage the application password subcomponents.
These are REST API updates.
And then these are all the open tickets.
So there are 6.5 tickets that I've been working on,
worked on for, sorry, 2 bugs that have been worked on for 6.5.
3 enhancements, no feature or twist, and no blessed tasks.
I'm not quite sure what a blessed task means.
If anybody knows what that is, let me know.
I think it's the case of this is like a new piece of work that we need to get done
and it's been given sort of permission to work on.
But I've never quite understood that one.
And then there are 34 issues awaiting review,
34 bugs, 38 enhancements, 7 feature requests,
22 bugs that are sort of set for a future release,
30 enhancements to feature requests and 4 blessed tasks.
I'm going to open that quickly.
And just want to see what blessed task means.
And I think blessed generally means that everybody agrees
this is a good idea and we should do it.
I'm trying to see when it was updated.
I don't see it being updated to blessed.
Maybe it was when it was created.
As per discussion, I think it's possible.
I guess it might have been when he created it.
I've never had clarity as somebody who's been contributing to WordPress
for not that long, maybe 7 years.
I've never had clarity as to who blesses a task.
Is it the maintainers?
Is it the project leadership?
Never quite figured that one out myself.
So yeah, it must have been when it was created.
It was blessed.
I'm actually going to dive into if I can figure out why this is.
So let's go and have a look here.
Search for blessed.
I'm looking for, hopefully, some kind of documentation
about what a blessed task is.
Might have to go pink, somebody asked.
Maybe Google will help.
Let's have a look here.
Maybe there's something in the handbook.
There we go.
Features development for the upcoming major release
enters around task tickets, which are major features
on important enhancements that have been blessed by the core team.
A ticket should otherwise never receive this designation.
So it's a major feature, important enhancement
that has been blessed by the core team.
So those we should probably leave alone.
Alrighty then.
So where was I?
I've lost where I was.
Let's go back a couple of pages here.
That wasn't there.
There was a chair.
No, it wasn't chair.
It wasn't chair.
Just here, there we go.
So that's one place where you can find REST API tickets.
The other place where you can find tickets
is in the Gutenberg repository.
Sorry, I just noticed that somebody posted something in chat
and I just went to looking for a future
to call Harry Shankar the week before the new year
and he suggested I start collaborating
and look for groups to join and also Easybug to start fixing.
Mainly front-end.
Cool, welcome.
I hope that you learned something today.
I'm mostly back-end myself, so we're not going to be really looking
in front of any things, but hopefully that something sparks.
Based on that surname, that looks like James.
James, if that's you, say hi.
James, let me change before it previous live streams.
So it is James. Hi, James.
Okay, so the other place that you can look for REST API issues
is in the Gutenberg repository.
The reason for that is because Gutenberg uses the REST API
under the hood for practically everything it does.
So the way to find those there.
This is one of those things where it's kind of difficult
to know where to start looking for things to work on
if you've never contributed before.
My suggestion would be to get used to track,
which is what we're in here,
core.track.weirdpros.org.
We'll dive into how this all works in a second.
But with Gutenberg specifically,
the Gutenberg project is the site editor.
Everything kind of happens there.
There are also often some issues in the Gutenberg project
that are around the REST API.
So to find those, you can click on Issues,
and then you can search for the REST API interaction.
So there's core REST API tasks
of which there are currently four open ones.
Some of these are quite old.
We'll have to go through those.
And then the other one is there is a--
backspace there--
there is another REST API label called REST API interaction.
And in that one--
let me just untick this--
there are 48 open issues.
So different places you can find issues to work on.
The difference with the Gutenberg ones
is that we'll go into the Gutenberg plugin,
which will eventually get merged into core.
The ones on track would be merged into core pretty instantly.
So I'm not quite sure which way I'm going to go yet.
I was kind of looking at the list in track.
So there's 32 tickets that have no replies.
What I'm going to do is I'm going to start
by looking at issues that are part of the REST API component.
So to show you how that works, if you go to--
and it is a bit of a minefield to know where to get started
and look for issues, I'll be honest.
But if you go to core--
this is not pasting--
if you go to core.track.weirdpress.org,
if you don't know, it might be useful to share.
But track is actually just an issue tracking software.
It's been around forever.
Track-- bug tracker--
track project.
It's similar to things like Bugzilla, to Mantis,
to Jira, those kind of things.
It has been around for a long time.
Let's see how long it's been around.
2004-- so right about the time that the first versions
of WordPress were released--
and so at the time, I'm guessing,
Matt chose to use track as an issue tracker.
And it's kind of stayed that way ever since.
Back then, we used track and we used SVN
before things like GitHub and Git were developed.
But this is where most of the issues are logged.
Many of the issues that are in the Gutenberg repository,
specifically to the current versions of WordPress,
are brought over to track.
So most of the time, you can find which one you're looking for in track.
And the way to start searching is to click on--
you can either click on components
and then click on the rest of the components
and go through the way I just showed you.
Or you can just search and click on the tickets option.
And you can do something like latest tickets
or whatever the case may be by major release,
whatever the case may be.
So let's go to latest tickets, for example.
And you'll see all the latest issues.
And you'll see they belong to different components,
et cetera, et cetera, et cetera.
I prefer to go via the components.
So I usually go components, and then I go--
where is it now?
Rest API.
And then I have a look at all of the issues
that belong to the rest API.
So I'll click on-- not that one.
This is kind of not what I'm looking for.
What I want is just a list of all issues on track.
So what you can do is you can actually create your own.
So let's go to open enhancements, for example.
So here we go.
So the way you can do this--
OK, let's go all the way back to track.
So there we go.
And you can design your own query.
Or you can go here.
Here we go.
Where was that?
No.
Let's do that again.
Tickets.
Here we go.
Tickets by component.
So you can go tickets by topic, tickets by release,
tickets by focus.
So if we set tickets by component
and we selected rest API, that would then list all of the rest
API related issues.
So this is a nice way to look at the overview.
You can see there's 100-- 1 to 100 of 143.
These are slated for next release.
So these are currently being worked on for the next milestone.
So I'm not going to try and get involved in any of those.
Folks are already working on them.
Then we've got tickets awaiting review.
So these are tickets that have patches or needs unit tests
or whatever the case may be, which means somebody has created
a patch for it and it needs to be worked on to move forward.
Candidates for closure.
Tickets needing feedback.
Tickets with patches.
And then right at the bottom of the list,
there will probably be tickets that are new.
Unpatched bugs, for example.
Here we go.
Unpatched enhancements.
Here we go.
So that's kind of-- if you want to work on something fresh
and new, you can kind of find those over there.
That having been said, it might be useful to look at some
of these tickets that have patches and maybe test out
the patch.
It might be easier to start helping out with testing
a patch or writing unit tests for a patch.
That might be something I look into.
Or, for example, if we go back one page here,
tickets needing feedback.
No, not tickets needing feedback.
Which one was it now?
Tickets awaiting review.
So we could look at it and we could see, well,
let's have a look at this one, for example,
creating an anonymous comment with custom fields via REST API.
I'm able to successfully create anonymous comments via--
let's see here.
OK, talking about possibly closing this one out.
So I'm not going to worry too much about that.
So the best thing to do is to kind of look
through each of these tickets and sort of see, you know,
which ones work for you.
What I think I'm going to do today is I'm going to try
and find one that needs some testing.
So these all have a patch, but they probably need testing.
So let's have a look at this one, for example.
Expose menu data public in menus REST API.
How's the patch?
It's a proof of concept PR, so I think it needs more feedback
from folks that are involved.
It's not really something I feel like working on.
I'm wondering now if it makes sense to focus on REST API,
and maybe it makes more sense to find some other kind of bugs
to work on, just to kind of get ourselves
comfortable with fixing bugs and creating, fixing things.
And then we can come back to REST API focus later.
Because REST API is very specific.
You have to kind of have a good feel for how the REST API works
and what it does.
And also, I would like to find out from folks if they have any
sort of good first issues they would like folks to work on.
So while we're on that topic, inside of the Making WordPress
Slack, there is a core REST API channel where you can go
and ask questions.
I don't know how easy it's going to be.
So I'm thinking maybe I should post some kind of question
around where folks would find benefit.
I'm not quite sure myself to be honest.
So the other thing that we could do is we could do this.
Go new custom query, and we can say, let's take that out of the way,
and we can say component is REST API.
And take away assigned, take away reopened,
and I'm going to take away reviewing.
And I'm going to refresh that.
So that might give us an idea of some new bugs that we could
work on.
If I don't find anything amazing, I might just go and look at
something else.
This seems to be taking forever now.
It's maintained, fallen over.
There we go. Database is locked.
There was an internal error in track.
Okay. Let's try that again.
So let's go design your own query.
Report through Cypress. Let's remove that and update.
So those issues that I've worked on, okay, that's better.
And let's go component is REST API date.
Okay. That seems to work. Okay.
So now let's take out anything that is assigned,
anything that is reopened, anything that's being reviewed.
There we go. Okay. Now we're getting somewhere.
All right. So this is 118 issues that are in the REST API
that are sort of accepted as valid issues.
They are new. Nobody's working on them.
So that's one way to do it. So you create your own custom query,
select the component you want to work on, maybe just keep
accepted a new enable.
You can group by status, severity, resolution.
You can show description and each result.
That might be useful. Let's do that.
There we go. So now we're getting an idea of what's going on.
Although that's not the most readable.
So I'm going to not include that.
And now you can kind of go through and you can see what they're
talking about. So we've got HTTP status codes
and you've got supporting dates, add accessor functions
for post status and post parent, default query for users.
I'm looking for sort of easy, simple.
I see they do have priorities.
It's not really easy to see if anything would be considered
a good first bug here. So you kind of have to go through
and open up the issue and read through it to see if it makes sense to you.
Add a REST nonce action to the REST API. That's interesting.
In the spirit of fully customizing the REST API as I'm doing my
work to do some features, a customizable filter,
not the nonce name or rather the REST nonce action is not.
Don't if your REST is a bit generic and could easily have
REST nonce name or Rensselin's action filter added.
Thoughts?
So there's a patch.
You should apply them in form of a patch, not the entire source file.
You can find more information here, stop by there.
Patch added, patch submitted, something along here would be alignment,
patch updated.
What are practical using this filter would be for site change, the REST API.
Action filter, all the plugins that we're creating, REST nonce,
that's what I was thinking when I read through this.
As such, the practicality here seems quite small and probably be
served by custom authentication filter because of that.
I think it makes sense to close this ticket.
That's where it ended up.
This is a bit of a dead end.
So you keep going and that's essentially how you find a ticket to work on.
You read through it, you find whether it's interesting,
whether it's something you can handle,
and then you see if you can fix it.
This one says incorrect HTTP status code.
Let's have a look at that one.
Specify posts when I request a status,
I get the error status is forbidden.
Problem is not the request status keeper is valid,
but the request in draft requires authentication.
I'd like to request that HTTP status 401 be returned instead of 400.
Okay, so there's a diff.
So in case you're wondering what a diff is,
we'll tell you about that in a second.
But let's read through here,
converting to a bug considering the wrong HTTP returns here.
Change your status 400 with 401 for when I request it to do some
unit tests.
Some unit tests that had assertions checked.
Return status code was 400,
having been changed to some unit tests that had assertions
checking returns status code was 400,
have been changed to check that restricted status code is 401.
So this one has a patch by the looks of it and needs testing.
So this might not be a bad one to test.
So let's have a look.
This is the diff.
So if you're wondering what a diff is,
a diff basically includes the changes or a patch, if you will,
include the changes that would be made to the file in a special format
that you can apply to your checked out version of WordPress,
of WordPress call.
And then you can test that things work the way they should.
So the changes being made here in the access,
the person gets the error code,
if it's in that parameter,
if not listed error code, error code is whatever the error code is,
or pass 400.
The problem here is that changes status 400 with 401 for unauthorized requests.
If it's . here is a sanitized value.
See, I need to spend more time with the rest API to understand
how this works.
So I do feel like,
attachment controller, page controller, post controller.
Yeah, that's already one I feel comfortable testing,
so I'm not going to get in there.
Okay, let's go back here.
Our conditional field registration,
I had generated select rest API to this endpoint.
Rest API approach, page response includes scripts needed for this layer post content.
Interesting.
Often the post part is painted on external strips and child sets
in order to be displayed correctly,
but there's no way to discover what these scripts and style sheets are.
The problem was encountered in Gutenberg on that,
and the next was to filter the rest API response to include the list of scripts.
You can't know what the scripts are required ahead of time,
especially if the API code goes around a different server.
This looks a bit bigger than what I...
Use get blog window in the rest API index, okay?
Rest API provides data on the site index, so we're making a request to that.
This describes the sites and the APIs.
This has patched keyword second opinion, so a patch has been added.
[silence]
I'm not going to get involved here.
[silence]
Uploading doing it wrong should write...
Doing it wrong should write into debug lock. That's interesting.
[silence]
I created a plugin that called to register rest root with our permission callback argument.
It worked fine until WordPress 5.5 that this argument is now required.
However, the errors don't appear anywhere except the rest API headers,
but it's hard to notice about that.
I keep using the old code because I didn't know this changes now
and it's not showing in the debug lock.
So one day WordPress 5.8 is released and I entered into the new widget management
and all errors appeared in the debug lock.
The function doing it wrong is useful and should write the details into the dealer
no matter where it is called.
[silence]
So this is interesting because I threw...
When was this created two years ago?
I remember... Hmm. This is interesting.
[silence]
I remember seeing something about this when I was working on some rest API content.
[silence]
This could be one that I could work with. Let's have a look.
Okay, so this was open two years ago.
If I hover over that, it'll show me.
It was open on the 16th of January. No, the 16th of January 2022.
So just before I joined automatic.
And I remember doing some work on creating rest API endpoints
and not setting the permission callback and not throwing an error.
So let's... Okay, so this has no conversation on it, which is cool.
So we should actually be able to test this out. Always fun.
So what I'm going to do is I'm going to open up the rest API handbook
and going to add a custom endpoint, which is what I think this person is doing.
Register rest root.
Register rest root, yeah.
Yeah, register rest root. That's it. Okay.
So we're going to just steal this code here.
I actually think I did this in my Learn WordPress content, so let's have a look.
James says, "So the core track is just the list of everything.
I'm looking for some front-end issues."
Yes, James, essentially core track is everything.
If you're looking for front-end issues, your best bet would be to select
a component that has more of a front-end focus.
So when you say front-end, do you mean the front-end of the dashboard
or just any front-end related problem?
Because you could possibly look at administration or the dashboard at least
and then find some front-end issues there.
Let me go back to where it was at now.
I've lost it. Let me just copy this into my thing, actually.
Then based on, or you could look at, for example, next major release,
and you can find anything in there.
It does require you to do a little bit of digging, though.
So you're not easily going to find just front-end issues.
You're going to have to get used to how a track works and do some digging.
The best thing to do, so I'm going to share this quickly as well.
This is back to the other question earlier about the link.
So the handbook link, let me paste that quickly.
Let me just share these links again.
So it's make.wordpress.org/call.
That's the first one.
Then the handbook is there.
Then the handbook is this link over here, so I'll just copy that out.
That's the handbook there.
James, you also mentioned about block editor functionality and usability.
So if you're in track, you should also be able to, if you go to components,
you should also be able to go to the editor component.
There, editor.
The editor component would be the block editor,
so it's integration of the Gutenberg block editor,
maintenance of the classic editor, and all those related things.
So that would be another place you could start.
But I want to also share this with you as well.
Let's go back to the call blog.
If you look on the call blog here and you scroll down to the right,
they have regular chats and they have a new contributors chat.
And the new contributors chat happens on the second
and fourth Wednesday of every month.
So if we have a look at where we are now,
the second Wednesday would be next week, 14th of Valentine's Day.
So the 14th and the 28th of February,
there will be a new contributors chat in the call channel in Slack.
And essentially, let's hop on over to call
and let's find the new contributors chat.
I think they might notify when it starts something.
Here, new contributors.
Sega's asking, second third.
So it does look like it is still on the go.
So you can join the call channel at that point
and then ask questions and say,
"I am interested in working on these kind of issues."
And usually there will be folks around to help.
It's at 1900 UTC, which is whatever that time is in your local time zone.
But you can enjoy the new contributors chat
and you can chat to folks and you can find out how things work.
And then usually soon after the new contributors chat,
they have the weekly developer meetings,
which the next one is this coming Wednesday at 10.
That's eight UTC, GMT plus two my time.
And you can then follow along in dev chat and see what people are working on
and you can possibly ask questions there as well.
So have a look out for those meetings.
If you click on the "see all meetings" link at the bottom here,
you can then see all the meetings that are happening.
It doesn't look like the-- there it is.
There's the new call contributor chat.
So on the-- this is January, so if we hop on over to next month, February,
and we go to the-- it'll be what is this? 14th.
There, there's the new call contributor chat.
You can click on that and you can add it to your Google Calendar
or whatever calendar you prefer to use and then it'll remind you.
And that is a great place to chat to folks, ask questions, say to them
what you're interested in, what your experience is,
where you want to get involved, and then they will help you get going.
And also what you can do in those sessions is you can bring questions.
You can say, "I've been working on something.
How do I create a patch? How do I do this? How do I do that?"
I'm going to try and go through some of those things later in this process,
but that is where you can also ask for help and ask to--
and they'll point you in a good direction of what you should work on.
Okay, cool.
So for me personally, I'm going to have a look at this bug quickly here.
So what I'm going to do-- so what I've done is I have got my local development environment set up.
I'm running this-- I just want to show you quickly--
I'm running this on a fork of the WordPress develop code,
which is a repository in my local GitHub account.
There it is there, WordPress develop.
And the reason I'm doing that is because I'm not a core contributor,
so I don't have a way to easily create pull requests and those kind of things to WordPress develop.
So the easy way to do that is if you go to the WordPress develop GitHub repository,
which I'll paste into the chat with you,
also check out that YouTube video that I posted earlier.
I'll share that again in a second.
You can click on-- there's a fork button.
And if you click on the fork button, it'll ask you to create a fork in your repository.
You click New Owner, so your mind already exists.
So I can't create that, and then it forks the code to your account.
What that allows you to do is it allows you to create pull requests, branches, all that kind of thing.
And you can also keep your fork in sync with the WordPress one.
So you just click Sync Fork, and you say Update Branch,
and it'll make updates and all it needs to do.
And now it's up to date with WordPress Trunk.
See-- oh, what's his name?
I forgot Pascal.
Pascal recently committed some changes, so that's why I needed to get updated to.
So that's why I needed to get updated there, so there it's updated.
And then in my local WordPress develop, I'm just going to go and get pull,
and I'll get the latest and greatest of whatever version this is.
So if you want to work on Trunk, that's a good way to get started.
If you're used to working in GitHub, that's an easy way to get going.
But do check out the YouTube video.
I'm going to share that again.
I'm going to copy paste that from earlier.
Do check out the YouTube video, because it talks about how you can set up the local environment
and all of that stuff if you want to know how to do that.
All right.
So I am going to go ahead now, and I just want to actually check something.
I want to check what time-- how long I set these for,
because I think I've only got 15 minutes left.
Oh, I actually was meant to start at 3.30.
What time did I start?
Did I start at 3.30?
Let's check.
No.
Yes, I did.
I started at 3.30.
OK, so I do have some time left.
I see someone's chatting in the event chat.
Let's just see what's happening there.
OK, so I'm going to just see that.
All right.
So if I start at 3.30, we've got another 45 minutes.
OK, cool.
So the way I'm going to try and fix this is I'm going to try and--
in fact, I can probably use this person's code here.
So let's go over here.
I'm going to create a plugin in the source directory,
WP content, plugins.
I'm just going to create a very simple little plugin here,
and I'm going to say example plugin.
And then I'm going to grab--
I'm going to let GitHub CodePilot just generate some plugin
header for me.
And I want plugin description.
There we go.
And then I'm going to grab this code.
And I'm going to pop that in over there.
And I'm going to change this from my plugin to example plugin.
OK, and we'll make that example plugin all items.
Call back my plugin get items.
And then I'm going to create the callback function.
I'm literally just going to return a list of items.
That's all I'm going to do there.
OK.
And then the only other thing I'm not sure of is, I guess--
I guess the local development environment is going to log
the debug log to the WP content.
So let's just check.
So if I go into my local, which is somewhere here--
that one.
If I'm getting very hot chairs, I'm going to pop the fan on
inside of my desk.
It's very, very warm here in GitHub Code.
So hopefully the fan noise doesn't come through anyway.
So let's go to the list of plugins.
And I should see my example plugin there to be able to enable it.
I don't know why, but I find--
OK, let's just see here, WordPress connection.
Yeah, this I sometimes have.
So there's my example plugin.
I'm going to activate that.
And I'm going to check if the--
yeah, there's the debug log.
OK, excellent.
OK, I keep getting this service issue with--
I'm going to just quit this.
I'm going to restart the local server.
Pop it.
I'm running in vstart.
See if that fixes those issues.
[
I don't know if it's a Docker thing.
It tries to connect to WordPress servers to do a sanity check--
not sanity check, heartbeat check, and it fails.
And so far, the only way I've figured out to work around it
is to install a plugin called Flight Mode and enable Flight Mode,
which basically disables any requests to external sites.
So let's download Flight Mode while I'm thinking about that.
Flight Mode or Airplane Mode?
Airplane mode.
Yeah, it's this one.
I thought this was--
I think it is in the plugins.
Let me just go here.
Ah, new keyboard.
No, not that one, that one.
Yeah, there it is.
So I'm going to just download this quickly.
Stick it on my desktop.
And let's upload this.
And install it.
Now, why this happens, I don't use Docker a lot.
I hate Docker personally.
So I couldn't be bothered to try and figure out why it happens.
So I just install Airplane Mode,
and it basically turns off all the external requests
and it stops that error happening.
So I'm going to just install this quickly.
Okay, it should be installed now.
Yes, please.
I get this on my local learn development environment as well.
Yeah, there's a little bit of it.
Activate it.
If this keeps bothering me, I might just one day go and dive into why it's happening
and see if I can figure it out.
I'm pretty sure it's a Docker-related thing.
Okay, Airplane Mode is now active.
So now we should find that things are a lot faster.
Okay, so let's have a look at our DebugLog.
DebugLog is logging everything, so let's delete that.
All right, so let's go back to our plugin list.
Example plugin is active, which means I should be able to now browse to all items.
Let's try that.
So it'll be...
I can never remember the URL for this.
So it'll be WP JSON.
I think, yes.
And then it will be example plugin, I think.
All items, yeah.
Okay, so that's what I wanted.
And now the permission callback is not set, so it doesn't...
Okay, so I remember coming across this recently.
So let's have a look here.
See now in register-race-root, they talk about the fact that you...
See it somewhere.
Yeah, since 5.5.0, there is a notice if your registration of register-race-root
is not including permission callback.
You may get some notice in DebugLog, like the following one.
So there's probably a need to add the permission callback.
Now, I haven't doubted it, and it's not throwing an error.
And that's essentially what this person is saying.
So what I need to check now is why it's not throwing this error
and then get that to log to the DebugLog.
So my guess would be if we go into register-race-root,
which we can do from here.
And this is one of the cool things I like about IDEs.
Often you can select... if you've got it all set up correctly,
you can select the function, and you can hold down alt or your Mac key
or whatever, and you click through to the function itself.
But this is in the...
WP includes REST API.php file.
It's the register-race-root function.
There is the doing it wrong call.
And let's see if we see the permissions callback.
Permissions callback.
If not set permissions callback, doing it wrong should be called.
If not is set permissions callback.
Okay. So it looks like it is doing what it should be doing.
What are doing it wrong?
The current behavior is to trigger user error if debug is true.
So let us...
Let's do a quick noun.
This is where it's going to get interesting.
OHR access key, R group.
Okay. So it's R group.
So let's do a quick...
Let's just do a quick...
var dump of R group.
And then just die.
Now I wouldn't normally do this.
I would normally set up XD bug and those kind of things.
But I just want to see if this gives me anything useful.
All right. Go in further.
Okay. So here we go. So that's what it's giving us.
So let's give it some formatting quickly.
I just want to quickly have a look at the...
I just want to quickly have a look at what's inside of this.
The permissions callback is set and it defaults to return true.
This is the right one. No, no, this is the O embed controller.
That's not what I want.
That's not what I want. That's not what I want.
So let's do that. Maybe we'll get somewhere.
O embed. Wait, you know what we need?
Namespace root. So if namespace and root are example plugin and all items.
Let's do it that way.
So that should only trigger if that namespace is being called.
It'll do it for all items, but that's fine.
I just want to get a feel for what's inside of that very well.
Let's have a look at that.
Oh, wait. So I didn't specify.
Let's try that again. There we go.
So permissions callback is not set.
It should throw that error.
So it is doing it wrong.
Not output.
That's interesting.
So this is not an issue with the REST API.
This is an issue with doing it wrong function.
Hey, boom, boom, boom.
Just sort of trigger error does.
Bail if debug is not turned on.
That's fine. Do action trigger error run.
And then trigger error.
I wonder why it's not happening in the REST API.
Okay. So I'm going to have to set up Xdebug and step through all of this to see why it's doing that.
But it's not actually a REST API error.
It could be interesting error to dive into.
So yeah, I don't know if that's what I want to work on.
I'm going to bookmark this one just as a...
I think what I'm going to do is comment on this.
Actually, you know what I'm going to do?
I'm going to copy the link.
I'm going to post a question in the core REST API.
And I'm going to ask, "Hi folks.
I was looking at this issue today.
From what I can see, the problem is not REST API related,
but to be doing it wrong.
And if not, is it Mission Callback? Yeah.
I'm going to do this to the take it wrong reflection.
I'm doing it wrong.
Where's that fall under? It falls under functions.
The main WordPress API.
Main WordPress API. I'm going to do this component for that.
Visual
options.
In the mail, there's import.
General. General might be one option.
It's not crumb. It's not cache.
I can't say in general.
Yeah, I would say this falls under general.
Okay, so what I'm going to do is I'm going to post the question in core.
Looking into this issue, logged against the REST API component today.
Problem is not REST API related to doing it wrong function.
What I can't determine is which component that belongs to my initial fault.
Yes, general.
And I'm just going to leave it like that.
So hopefully somebody will come back and answer that question.
And then I could probably go ahead and update the component
because it's not a REST API related issue.
Doing it wrong doesn't seem to be working properly.
Or I'll just wait and see what folks say.
This is logged against the REST API today.
From what I can see, the problem is not REST API related to doing it wrong function.
What I can't determine is which component that belongs to my initial fault is general.
So I'm going to post that. I'm going to see if folks come back with a response on that one.
But yes, essentially that is how it goes when you want to contribute to call.
You find an issue that is within the component or the area that you want to work on.
You try and test out what the person is saying.
You can either ask questions in the core channel if it relates to call or some component.
And then you move on to the next one.
As I was saying earlier in this stream, if you missed it,
if you want to work specifically on Gutenberg block editor related things,
then your best bet is to go specifically to that GitHub repository,
which I'm going to paste now here.
In the Gutenberg issue list, I do think they have a good first bug option.
Yeah, good first issue.
So it might be useful to filter by those and scroll through and see what you can find.
If you want to contribute to Gutenberg, you need to fork and check out the Gutenberg repository specifically,
which is a lot easier to set up than setting up WordPress call.
You are essentially contributing to WordPress call.
It'll just probably only get merged in much, much later, but that's another option to look at.
But if you're working specifically with current WordPress call, it's going to be track.
It's going to be looking through the tickets, setting up queries, looking for things that you can work on.
One other way to do it, to look for good first issues, is look at the next minor releases
and see what is going on around there.
This thing's not doing what I wanted to.
Patches that need testing, also a good one.
There's good first bugs for new contributors under getting started,
so maybe click on that and go through those.
You'll see there's a whole bunch there.
But it does kind of require you to just sit down, read through it,
see if it's something you feel like you can work on.
One of my colleagues, let's see if I can find him here,
he was lucky enough to have found bugs.
I'm not going to find it. One second here.
He has been fortunate over time to find bugs that are CSS related in the admin.
Oh, why is that not working? Hang on.
Is that not his profile name? Let me find him.
That's weird. Anyway, I can't find his...
I'm sure that was his username.
Anyway, he's managed to find some bugs that were CSS related
and adding CSS here and there.
It does require a little bit of diving into tickets,
reading through, seeing what you can find.
Bundled theme is usually a good one to look for as well.
That often has CSS related things.
Administration will often have...
Replace EM-based line height with unitless values.
That's something that folks will probably work on.
You do have to look for one that hasn't been worked on.
You need to get comfortable with track and go from there.
I'm going to wrap up today.
I'm going to keep this doing it wrong one handy
and maybe I'll work on it next week. We'll see if I get a response call.
If you are new to contributing, I do recommend trying out those new contributor chats
or just pop into call and...
Oh, look, someone's replied. General sounds good to me.
Awesome. Thank you.
Some folks have come back. Jonathan Desroges.
Thanks, Jonathan.
What I'm going to do...
I'm going to wrap this up. I'm going to go up over here.
I'm going to do this. I'm going to say...
Hi, Oakby. Thanks for logging this issue.
It looks like this isn't specifically REST API related
and more that the doing it wrong function isn't logging to debug log
in the scope of the REST.
Actually, it might be because of where it is.
It's not about it. It might be because of where it is.
I'm going to need to test this further.
Here's what we're going to do. I'm going to leave it as is.
Next week, I'm going to try and see if I can figure out how to get
Xdebug working in the WordPress develop core code base which runs Docker.
I've never done this before.
Let's just see if this is WordPress develop Docker Xdebug.
It does seem to be some information about how to do this.
That's what I'm going to do because next week I want to step through this code
and see what's set up and why it's not working.
Maybe because it's in the scope of the REST API, doing it wrong
I'm not quite sure, but it looks like it should be doing what it should be doing.
It looks like doing it wrong should be being called and logging to the right place.
I need to figure that out. Next week, I think that's what I'm going to do.
I'm going to figure out how to get Xdebug set up.
I use PHP Storm as my IDE and I have PHP Storm set up
as the using the zero configuration thing.
I think that's what I'm going to do.
I'm going to spend some time configuring Xdebug for PHP Storm
and the WordPress develop code base and then we're going to step through this issue.
Let me make a note of that bug.
I'm going to just copy it and save it somewhere.
Then next week, we'll carry on with that.
If you want to watch the recording of this, I don't know how interesting it is
to watch the recording of a livestream, but if you want to watch the recording,
you can do at the WordPress YouTube channel.
It'll take me a couple of days to get it uploaded to here,
but I will upload it this week and there's the previous one.
You'll be able to find the new recording so you missed anything
or if you want to see anything again, you can check it out there.
Then yes, next week, hopefully you're going well.
We will set up Xdebug and step through that code and see what's going on there.
In the meantime, if you have any questions around all of this,
you are welcome to send me a private message in the making WordPress Slack.
You can find me there at any time.
Feel free to ping me with any questions around this.
If you're busy getting it set up, if you want to know how to get started
with contributing to WordPress, you're welcome to send me a ping
and I will try and find the answer for you.
I think I'm going to wrap it up there.
I feel like I've done enough today.
I know I've still got 20 minutes left,
but I can't think of anything else to do for the next 20 minutes.
Thank you for joining me today.
I hope that I've been able to enlighten you in some way
as to the process of contributing to WordPress.
Okay. That's me done. Bye.
[END]
[BLANK_AUDIO]