Good day, everybody. It is Thursday. It is Let's Code Thursday. Welcome to this online
workshop. As you are joining, please do let us know in the chat where you're joining us
from. And then please share a little bit about what you do with WordPress. I'm curious to
know what your involvement is with WordPress? Do you use WordPress for work? Do you contribute
to WordPress? Do you do both? Do you just use it for personal sites? Please let me know in the chat
so that I can get to know where everybody's from and what everybody does
in and around WordPress. While you're doing that, I will do my usual introductions.
My name is Jonathan. I'm from Cape Town in South Africa, which is right at the bottom of Africa.
I'm currently a developer educator at Automattic,
and I'm sponsored to work with the training team.
The training team are the group of folks
that primarily work on learn.wordpress.org.
We create tutorials, we create lesson plans,
we run these online workshops, we create courses,
and we also try and fix bugs
and improve the Learn WordPress platform.
So that's my bit.
Welcome Adrian from Southern California.
Adrian says, "I use WordPress for small client websites."
Great. Welcome, Bud. Bud is from Natalee, New Jersey.
Bud says, "Always learning new stuff to help me create WordPress content for WordPress businesses."
Excellent. So welcome to Adrian and to Bud.
I've got a few other folks joining, so I'll let them
sort of start feeding through their information.
Sergio says hi all from Washington state. I do some development plugins, etc. Excellent. Welcome, Sergio. You are my people. And I support WordPress sites for nonprofit.
But says love your presentations. Thank you, but I appreciate that. I am hopefully getting better over time.
I was thinking about this the other day.
I remember my very first online workshop and I was very, very nervous because my
presentation style, if you will, is built around doing things in person,
interacting with people in person.
And so the first time I did an online workshop was very daunting for me, but I
feel like I've gotten comfortable with them now.
Spelling Deafy doesn't count, you're correct.
We don't worry about spelling in these workshops.
Cynthia says hi from Ontario, Canada.
Hi, Cynthia.
I use WordPress every day as a developer
and maintain client sites for an agency.
Okay.
I'm also a WordPress educator
and could contribute to learn.wordpress.org.
That is correct, Cynthia.
If I'm correct, this is the correct Cynthia.
Cynthia recently, yesterday in fact,
had her first pull request merged
to the Learn WordPress website.
So she submitted a pull request to the platform
fixing a bug with the search field, if I'm not mistaken.
And so that was quite exciting
to go through that process with Cynthia.
Welcome, Cynthia.
All right.
Please, as you're coming in, please do continue to let us know where you're from.
I'll hop back into the chat to read out any more answers that might come through.
It's always lovely to know where people are from in the world and what they do with WordPress.
So if you join, please let us know where you're from and what you do.
I'm going to continue along with my little presentation here today.
So today we are going to be focusing on the HTTP Request
API in WordPress.
The eagle-eyed among you may have noticed
that when I originally posted this on meetup.com,
it was just called the HTTP API.
And then in preparing the slides for today's session
and preparing the work for today's session,
I realized that that was slightly incorrect.
And I am a stickler for naming things correctly.
So I updated it to HTTP Request API.
And I will dive into why I did that as part of my slides
because I think it's important to understand
these different terms and these different namings,
but that is what we're going to be focusing on today.
Just reading some more updates.
Elliot says, "Hi, from Cheltenham, bit of a veteran.
I've been using WordPress since 2003, 2004.
That's way more than me.
For bespoke business websites,
development for custom themes and plugins,
meetup organizer from my local community,
and I plan to contribute more to WordPress
as and when I can.
Excellent. Welcome, Elliot.
Stefan says, "Glad to be here from Sydney, Australia."
Is that right?
Wow.
Welcome from Sydney, Australia.
It's quite late there in the evening, is it not?
Or quite early in the morning, one of the two.
12.05 AM.
Wow, Stefan.
I am honored that you are up this late.
Hopefully, you've got something to keep you awake.
I used to be a midnight owl, but as I've gotten older,
That's not something I can do much of anymore, so welcome.
Stefan says, "Been using WordPress since 2017.
Happy to connect here."
And he's shared his LinkedIn link in the chat.
All right.
Okay.
Before we get into the meat of today,
let me deal with some announcements
and I just need to make one small change.
Thanks to Asad, who is co-hosting with me today.
Asad, let me know today that he was available to co-host
and so I didn't have time to update my slides.
So there we go, I've updated them now.
So welcome everybody one more time and thank you to Asad,
who is co-hosting today.
It is his ninth co-hosting session.
So the next time he co-hosts,
he will have co-hosted for 10 times.
So please give him a big silent round of applause for that.
It's always great to have regular co-hosts who,
I don't have to train,
and Asad just knows what he needs to do
and he gets on with it, it's great.
If you have joined and you can't see my slides right now,
I am sharing my screen
and you should see an announcement slide on the screen.
If you can't see what I'm presenting,
please do let us know in the chat.
There is a minor, not bag,
but it's a little glitch with Linux systems,
where if you join and I'm already sharing,
sometimes you won't see it.
So if at any point in time,
I am sharing my screen the whole time during the session.
So if at any point in time, you can't see my screen,
please do let me know.
There we go.
So as I said, it's constantly, so it's perfect.
So let us just reset that.
So I'm going to stop the share
and then I'm going to move some windows around
because things overlap other things when I stop the share.
And then I'm going to share my screen again.
And then, Sergio, if you could just give us a thumbs up,
or a yes, or a can see if you can now see the screen,
then we know that it's all good there.
Great.
OK.
Then a note that we are presenting in focus mode.
So that means that a son and I can see all of your video feeds,
but you can't see each other.
This is just to protect everybody in the workshop.
We have had some issues of Zoom bombing in the past.
Thank you, Sergio, for confirming.
So just to prevent any possible Zoom bombing.
If you would like to enable your video
so that a certain eye can see you,
that is entirely up to you.
You don't have to, but if you want to,
you are more than welcome to.
And while we're saying that, I'm gonna say,
hi Adrian, I can see you there.
So thank you for enabling your video.
You are always welcome to ask questions in these sessions.
Something that my colleague Ben, I was fortunate to be an attendee this morning.
My colleague Ben, Ben, who works with me in the training team, he presented a
session this morning at 10 a.m.
my time and I was able to be an attendee and that was wonderful just to sit and
watch and learn along with other folks.
Something that he reminded me of is the fact that we want these spaces to be
safe for our attendees.
And so that's why we have the focus mode.
We also wanted to be a learning experience.
So it's an open opportunity to ask questions in the chat
if you have any questions.
If you don't like to use the--
I don't mind which way you ask questions.
Chat tends to be easier for folks,
because they can ask questions while the presentation is
happening without interrupting me.
But if you prefer to do it via voice,
if you don't want to type your questions,
you're welcome to unmute as well.
There is a little raised hand reaction that Zoom offers.
You can raise your hand, and then Asad and I will pick that up
and we'll give you the opportunity to speak,
just unmute and just go, "Excuse me, there are no... You won't get into trouble for interrupting
me here at all. I won't be upset if you do that." The only request that I do have is if
your question is unrelated to what we're presenting at the time, if it's maybe off on a tangent,
maybe keep that. I do allow breaks for sort of tangential questions. So keep it for that
moment in time and then ask it then, or otherwise just post them in the chat and when I take
breaks, we'll follow up on those questions and get answers for them. All right. If you
like to code along with me today. So these sessions that I run every Thursday, we generally have a
live coding portion. If you want to code along with me, please do get your local WordPress
installation up and ready. There are a couple of other requirements, but I'll dive into them in a
second. And then, as always, I do tend to speak fast when I get excited and I get excited when
I'm presenting. So if I'm going too fast, if I'm rushing something, please do let me know. You can
shout in the chat or you can unmute and ask me to slow down and I will slow down. If there's
If there's anything on screen that I'm jumping too far ahead, too quickly, let me know and
I'll pause it or share the link in the chat so that we can all catch up.
And then lastly, this is being recorded as mentioned at the start of the session.
So the session is being recorded and is being uploaded to WordPress TV afterwards.
So if you have to leave early, that's fine.
You can catch the rest of it on WordPress TV.
I usually do it the Friday or the Monday after my Thursday session.
If you're looking for more learning WordPress resources, you can go to learn.wordpress.gov/wordpress
WordPress.org.
And then if you're looking for more developer-focused news,
you can find that at developer.wordpress.org/news.
This is a fairly new-ish blog that has been launched
around about the beginning of this year.
And there are some great articles there,
all developer-focused articles.
All right, does anybody have any questions, comments,
anything they wanna say before we dive into
what we're going to be talking about today?
I'm going to grab a quick sip of something
to refresh my voice and then I will move on.
Okay.
So Joe says, will WP now work for the presentation?
Yes, if you've got WP now up and running and you want to use it, that's perfectly fine as well.
We're basically going to be working inside of one plugin file.
So as long as you've got a WordPress install that works,
and as long as that WordPress install
can make external requests.
So sometimes local development environments
have like a closed network, not all of them.
But generally, if you can't make external requests,
you'll get that error about your site
can't connect to the WordPress.org servers,
which I sometimes have on the Learn WordPress code base.
But anyway, but WPNow should work perfectly fine as well.
Okay.
Our learning outcomes for today, as I mentioned,
we're going to be diving into the HTTP Request API.
First, we're going to define what we're talking about
when we talk about the Request API.
And we're going to dive into some terminology,
because when it comes to APIs and API, HTTP, REST, request,
what do these things mean?
So I'm going to cover some of that terminology with you.
Then we're going to look at how we can use it to fetch data
from an external service, and how we can use it
to send the data to an external service.
We're also going to briefly touch
on performance considerations when it comes to sending
and receiving data outside of your WordPress site.
And then we're going to briefly cover
some advanced REST API topics.
When we're doing the fetching and the sending,
that's when we'll be doing the live coding portion.
And then the performance and the advanced topics
will be more of a theory behind how those things work.
Everything is documented
on the WordPress developer documentation.
So everything is there
and I will be sharing the links with you as we go along.
Then lastly, before we kick off, what I'd like to ask
is on a scale of one to five, how well do you
feel like you know this topic?
So one being you know very little or next to nothing
about this topic.
You've never even heard of the HTTP request API.
Five being you are a HTTP request king.
You are making requests and sends and gets and posts,
and you know all about these things.
You know what a header is, you know what a response is,
you know what a body, response body is.
If none of those terms mean anything to you,
you're probably a one.
If they all make sense to you,
you're probably a four or a five.
I consider myself a four in this area.
I have done quite some extensive work
with the WordPress HTTP requests API.
While folks are leaving their scores there,
I'm going to share a public link.
I've shared this before, this plugin in the chat.
It's the Seriously Simple Podcasting plugin.
It's the plugin that I effectively,
I wouldn't say cut my teeth on
when it came to API extensions,
but specifically API extensions
or API integrations for WordPress.
I cut my teeth on this project.
In this plugin, we built an API
as part of the app service that we were building.
And then we had to build a API connection from the plugin
to the, I'm trying to find it now, to the API.
So I had to build an entire,
what I call the Castos handler,
which connects to the API, sets up tokens
and all those kinds of things.
So if this is an interest of you,
to see how something like this would work in the real world,
I'm going to share that link with you.
We're not gonna talk about it today,
but it's just one way that it could be implemented.
I'm not saying it's the best code in the world,
definitely not 'cause I wrote it.
But it's something that you can have a look at
if you want to see how things might work in the real world.
OK, Adrian says she's a 1, Stefan says 2.
Zania, I hope I'm pronouncing your name correctly there, 1.
Sergio says 2.
Bad says I'm a 0.5, thank you, Bad.
Elliot is a 3 to 4, that would make sense,
because he's working with those kind of things.
Sania is a 2.
Kasaba says 3.
OK, so we've got a good range of facts, so that's excellent.
So hopefully for the 4s, the 3s and 4s,
learn something new today.
If not, maybe it's just a good refresher of how it all works.
All right.
Then let's talk very quickly about requirements for today
if you want to code along.
First two requirements are local WordPress install
and some kind of text editor.
I use Visual Studio Code just because it's
one of the most popular free open source code editors
that folks can use.
I use it for my presentations.
In my day-to-day, I actually use PHP Storm,
but I'm using VS Code today.
Then I did a little bit of research,
and I was looking for an API that we could use in the session,
and if anybody's watching this recording afterwards,
that doesn't require us to have a working API.
You'd have to have some kind of app that you sign up for,
like the GitHub API or a Stripe API or something like that.
And I found this lovely API called fakestoreapi.com.
And what that essentially is, is a fake store API.
So, and we'll talk about APIs in a second
and the terminology and all of that,
but it's a free REST API that you can use
whenever you need pseudo real data
for an e-commerce or shopping website.
And it even has a homepage,
it has documentation that you can go and read
just like you would any other API service
from any other kind of product.
You can create requests to get all products,
get a single product by the ID.
You can limit results.
It's really amazing for testing.
So we're going to be using this today.
So if you're going to code along with me, keep that open.
We're just going to be doing one or two API requests.
But it's a fun one to use if you're
busy testing your knowledge around how APIs work.
The data that you might be sending
doesn't get stored anywhere.
But it does give you a result that you can then work with.
And if you do an update or a delete,
it'll give you some kind of data.
So that's really, really cool, I thought,
and a handy tool to use if you're
busy learning to develop with HTTP requests.
And then finally, a test plugin.
So I have just set up a very simple plugin.
I'm going to share the link with you in the chat.
I haven't created this as a download,
because we're going to create this plugin live.
So I haven't made it a downloadable plugin.
But this is the code we're going to be using.
You'll see it just sets up a sub menu page or admin menu page.
And then the page itself just has a thing for products.
It has an action hook in it.
And the reason I put an action hook in
is because I wanted to be able to hook something into a hook
and then keep the code that we're working on in one place.
So that's going to be in this Learn Products Data function.
And that's where we'll be doing our HTTP request today.
So if you want to--
I'm actually going to do that now,
so you can watch me do it.
You can just hit "Raw" and that'll give you the raw PHP code.
You can select all of this.
You can then go into your text editor or however
you want to create the plugin file.
Go into your plugins directory in your local WordPress install,
create a new file,
and I'm just going to call my wplearn-http-api.php,
just to keep it super, super simple.
I'm just going to paste that code in.
Now, my VS code has given me a couple of red lines,
which are not huge errors,
so I'm not going to worry about them too much.
I'm also just going to format this code,
so it's a little bit better following WordPress coding standards.
But once that file is created in your plugins directory,
you should then be able to
enable this plugin in your WordPress site.
So if I now go over to my local WordPress install,
this one is my LearnPress site.
So I'm going to open that,
so learnpress.test is the local domain
that I have and wow, that's really zoomed in.
I don't know why that is.
Let's just reset that.
I must have been zooming in for things the other day.
So I'm just going to log into my local WordPress install
and I'm going to activate this plugin.
So if we go over to plugins,
there, okay, I guess Matt needs an update,
I'm not worried about that.
Now there is the Learn HTTP API plugin, version 001,
learning about the API.
I'm going to activate it.
There it is, there's the admin menu.
And if I click on it, it's just an empty page
in my admin dashboard.
OK, so if you're still busy with that,
I'm going to pause for a second, grab another sip of coffee
before we continue.
If you're ready to get going, then give me a thumbs up
or an OK or something in the chat,
and then we will start diving in.
All right.
It looks like everybody is good to go.
So thank you very much for that.
If you're not ready to go, you can let me know,
and I will slow down.
But let's start diving into things.
One of the things that I've just realized,
I can usually share my slides beforehand
so that folks can copy paste these links from the slides.
I forgot to do that today, so I apologize.
What I'm going to do is I'm going to share these slides
quickly now with you in the chat
so that you can open them on your side if you would like to.
I'm going to say anyone can view.
And I'm going to copy that link and pop it in the chat.
And then I will do the usual upload of the files
to the slide share and share it in Meetup afterwards.
but if you wanna copy and paste the links
that I'm working with, you're more than welcome to.
Right at the bottom of these slides,
I always add a resources tab.
So that's there if you want it.
And I'm going to open up the one, two, three,
four, fifth link here.
I'm gonna share it with you in the chat
so you can open it up there as well.
And this is the documentation
in the developer documentation on WordPress.org
in the common API section about making HTTP requests.
And basically it says, "Yeah, very often we need to make HTTP requests from our theme or plugin.
For example, when we need to fetch data from an external API.
Luckily WordPress has many helper functions to help you do that."
And those helper functions are basically what forms part of the HTTP request API.
And there are some examples of how to do it on that page.
Now, before we dive into all of that, I want to go back a couple of slides.
Just after the let's go slide, there is a terminology slide.
slide. I'm going to make this a little bit bigger so we can all see it. And I want to dive into some
specific words and make sure we understand what those words mean. So an API is an application
programming interface, which is a set of functions and procedures that allow one application to
interact with each other with another. So any way that you could interact with something else is
considered an API. So if you have used the register post type function, or if you have used the add
action or add filter functions in code snippets, those would be considered an API because you in
your plugin or your theme, one piece of software, are interacting with WordPress Core, another piece
of software, and doing something between those two pieces of software. The thing to the matter is
your plugin, your theme is loading inside of WordPress. Sure, I understand that, but it is
essentially the same concept. It's an API. It's an application programming interface.
HTTP is what's known as the Hypertext Transfer Protocol.
And this is essentially the protocol that the internet runs on.
So when you go to a web browser, sorry, a website,
you will probably know that your actual URL is either HTTP in the old days
before we had secure certificates, or now it's HTTPS.
So it's using the HTTP protocol to send and receive that data.
It is kind of the backbone of how the internet works.
And if you open up a URL, I'm on learn.wordpress.org now,
and you open up your developer tools in your browser,
I'm not gonna ask you to do that now.
If you know how to do it, please go ahead,
but otherwise just watch what I'm gonna show you here quickly.
And if you have a look at the network tab
in your developer tools, I'm gonna refresh this request here.
Let's go right to the top, there it is there,
and I'm going to zoom in on this.
Why can't I zoom in?
Okay, let's do it this way.
No, that's not...
How do I make this bigger?
It doesn't look like I can.
Anyway, so the request that I made
was to the learn.wordpress.org URL.
And it is an HTTP request.
So if I have a look at the headers,
the request method is a get method.
So a get method means fetch some data.
I get a status code or a response code of 200,
That's a default of an HTTP request.
And then there are things like remote addresses
and the response headers and all kinds of other things.
Then there is also a response.
And in the case of a website, the response is generally HTML.
So any kind of HTTP request makes a request to the server.
The server determines what type of request it is,
if it's a GET or a POST or whatever.
And based on that request and based on the data
that is sent, it returns some information.
In the case of a website, some HTML.
So that's when we talk about command plus and minus.
Thank you.
There we go.
That's what we're talking about
when we're talking about HTTP
and when we're talking about requests.
So anything across the web is usually HTTP
and request is when you ask the server for something.
Okay.
So then when we talk about an HTTP API,
we put those two words together.
An HTTP API is a set of functions and procedures
that allow one application to interact with each other
using the HTTP protocol.
So a web request is a form of an HTTP API.
I hope that the captions are not stressing
with my quick pronunciations of HTTP.
But essentially, any system that allows
you to make a request and receive some data
is considered an HTTP API.
You get different types of HTTP APIs.
You get some that respond with SOAP responses.
SOAP is an XML format.
You get some that respond with REST responses, which
about that in a second, you get some that respond with HTML,
so a web request, but they're all kind of HTTP APIs.
Then if we move on to the next page of terminology,
here we start talking about REST.
So REST is known as Representational State Transfer,
and it's a style, an architectural style or a software style,
that defines a specific set of constraints
for creating web services.
So in REST, they normally talk about you have to use the get,
request to fetch data. You have to use the post request to add data. You have to send
a, I think it's a patch request to update data, and then you send an elite request to
delete data. And generally, a REST HTTP API or an HTTP REST API will use JSON formatting
as your data that gets sent back instead of HTML. So when we talk about an HTTP REST API,
It means a set of function and procedures that allow one application to interact with
each other, the API part, using the HTTP protocol, the HTTP part, and then it uses the REST architectural
style.
And it's more commonly known as a REST API.
So the full name should be HTTP meaning it's going across the web, REST meaning it's the
style of service, and then API meaning it's this application programming interface.
But folks will often shorten it to REST API.
Now, I'm already wondering, why am I bothering to tell you this?
Well, it gets back to the wording that I was mentioning earlier
when I started putting together this workshop.
I referred to what we were going to learn today
as the WordPress HTTP API, which it's not.
It's an HTTP request API.
So it's across the web.
It's an application programming interface,
but it's for requesting data back and forth.
As I said in the previous step, an HTTP API
would be a set of functions and procedures
that only allows one application,
these are actually the other, used in the protocol.
So it's good to understand the differences.
However, this page, this Making HTTP Request page,
if you go back and look at it on--
this is how I remember it when I first saw the page.
It actually said HTTP API.
And I think because of that confusion of terminology,
they've updated this page to just say making HTTP requests,
because that name wasn't 100% correct.
Now I know this is me being super pedantic
and super sort of sticky about naming,
but I just wanted you to know the differences
of what the different terminologies mean.
And sometimes if you said to somebody HTTP API,
they might assume REST API.
And sometimes there's confusion.
I remember presenting a talk about the WordPress HTTP request API.
And somebody said to me, "But why are you talking about that?
There's documentation and it's REST and it's this."
And I said, "No, no, no, you're misunderstanding what I'm presenting on."
So there's some confusion even in the developer community
about what is the REST API versus what is the HTTP API
versus what is the request API.
So that's why I'm referring to this as the request API
because it's the API used for making HTTP requests.
Okay, I hope that wasn't too much of information,
but I just thought that was useful to get out of the way.
All right, any questions around that?
I see Elliot says,
and sometimes rest is authenticated as well in public,
that is correct.
Sometimes not, sometimes completely open.
Developer world is a minefield of acronyms and abbreviations
and it can sometimes get very, very confusing.
Awesome. Thank you, Felipe, for that. All right.
So then let us move on to what we're talking about here.
So when we talk about making requests to an external service,
we're talking about something like this fake store API.
You might be wanting to connect your WordPress site to Stripe
using the Stripe REST API.
might find, and this was actually my niche when I was a freelancer, I used to look for
projects where the client needed a specific API integration that didn't exist as a free
plugin on WordPress.org or a paid-for plugin either.
So they were using some third-party service that nobody really was using, but they needed
it for their company, or they were using some newsletter platform that wasn't very popular,
but their enterprise services decided to use it, and then they needed to interact with
their site.
So that was my sort of niche.
I enjoyed doing those kind of projects.
And that's why I spent a lot of time working with the HTTP request API.
It's a lot of fun.
It's a lot of-- it's interesting.
It's also the one area of development where unless you have a good set of tools to do
testing with, things can get confusing.
Because you're essentially in a page request or in an admin page request, you're having
to make some external request.
It's going to do something that you have no control over.
it's going to return some data, and then you have to make sure
that you have that data and you know what's going on with that data.
So it's fun.
To me, it's a fun type of development.
OK.
So the first thing that I want to do is I
want to show you how you can use the request
API, the HTTP request API, to fetch data.
If we have a look at the get all products endpoint in our Faker
stored at API, the URL that you would use to fetch the information is fakestored@api/products.
If you pop this into a browser, you will see, and in my browser, it's probably a little
bit neater than maybe yours because I have an extension installed.
I'm going to switch it to raw.
You'll probably see something like this.
And if you view the source of this in the browser, you will see that it's just a line
of text.
But if I take this text and I'm going to paste it
into something called JSON Pretty, which is a--
I don't use that one I use.
Which one do I use?
I don't see the one that I use because it's not
highlighted for me.
Let's use JSON Pretty Print.
Basically, this is a tool you can paste some JSON content
in here, and then you can hit Make It Pretty,
and it then shows you--
We have to go to the mind not working.
There we go.
And it shows you a tidier version of this JSON response.
So if you've never seen or heard of the word JSON before,
JSON is basically JavaScript object notation.
It's a JavaScript definition of how
we would formalize and structure data
to be sent across REST APIs.
What's nice about it, it's a string, so it's lightweight.
But it uses a specific format.
It uses the square brackets, the parentheses,
and a certain format for transporting data back and forth.
The nice thing about Fakestore is we can test that the get endpoint works.
By making this request to the Fakestore API products URL,
we are actually making an HTTP get request.
As I mentioned to you earlier, if I hit "Developer Tools" here,
let me switch off my browser window, I don't know why that's on.
But if you have a look in the network tab, let's refresh this again.
There is the URL, Fakestore products, there is the get request.
It's responding with a 200, which means we're happy with that.
And you should be able to use this for any public HTTP API.
You should be able to pop it into your browser.
Your browser will make a request and you can get that data back.
What we would like to do, however, is we would like to do this programmatically.
We would like to fetch these products and somehow store them
or display them in our WordPress site.
So if you have a look, if you go back to the documentation that I showed you,
you will see the very first item after making HTTP requests
is getting data from an external service.
Getting or fetching of any data, we use the WP remote get function.
So this function performs the request with a get method
and then returns the response. That's all it does.
So just like the browser, you make the request,
you send it the right verb,
it responds with the response,
and then you have to work with the response.
So let's do that. Let's do that in our plugin.
So in my Visual Studio Code, in the Learn Products Data area,
which is going to fire just after the products page,
I'm going to simply do that.
I'm going to say data equals WP Remote Get,
and I'm simply going to pass in--
Oh, no, that's not what I want.
I'm simply going to pass in the URL.
There we go.
And then just to make my life a little bit easier, all I'm going to do now is I'm going
to print R, which is a PHP function which will just print out all of the values in this
data variable.
It's going to look nasty.
Don't worry, we will fix it up later.
And I'm going to print our data in there.
And then just so that it looks a little bit neater, I'm going to wrap this in what is
known as pre-formatted tags.
So one there and then one at the bottom here.
Okay, that's all I'm doing.
I'm also going to make sure this code is neat and tidy.
And then I'm gonna copy this out and pop it in the chat
so that you can copy that on your side if you need to.
Okay, I see that Sergio and Felipe
have shared the status codes.
Thank you for those.
We will dive into those status codes in a second.
But this is the code we're working with.
So this is just a very simple
get the data from products,
or sorry, get the response from products,
pop it into the data variable
and then just print out that data variable on screen.
So that's all I wanna do now.
Let me show you what that does and what that looks like.
And it's a whole bunch of stuff.
So let's dive into this whole bunch of stuff quickly
and see what we're getting when we respond,
when we get the response from the request.
So we receive an array of information, which is great.
We can work with arrays.
The first item in the array is the headers.
So if you remember when we were looking at the request
in the browser, there are always headers
that are getting sent back and forth in any request.
There are certain hidden bits of data
that get sent back and forth.
The server will read those headers
and do something with them possibly.
And sometimes when the server responds,
there are certain headers that are useful.
We'll talk about those in a second.
So there's always headers in any kind of request, or usually.
And the headers are various things.
They've got the date, the content type, various other things,
what type of server this is running on.
So we can see that the server we're requesting from
is running on Cloud Fair.
That's interesting.
And various other bits and pieces of information.
Then there is the body.
So the body is typically the data.
And as you can see, it's that JSON string
that we looked at earlier.
So that's typically the data that you're
going to be working with to be then displaying it
wherever on your site.
There's also a response item, which
includes the response code and a message
to say, in this case, all good.
If it was anything other than 200, if it was an error,
then the response would be something else.
Either you don't have access or the server is down,
or you're not authenticated.
All of those kind of messages are usually
sent back in the response.
And then there's additional information,
like if there are cookies in play.
There's also an HTTP response object.
So this is the response object that
is used to make this request.
This is stored in the response as well.
and you'll see a lot of the data is duplicated here,
and then it closes that array.
So that's primarily what's sitting there.
The most important things you need to worry about
is your headers, if you need to read them,
your body, which is your primary source of data,
and then your response information
if you need to know whether things are happy or not.
So any questions on how to make a request to an API
using WP Remote Get before we continue?
As you can see, it's very simple.
It's one call and then you get the data
and then you can do something with it.
Any questions on that before we dive into the,
well, what should we do with it?
Which would be the next question.
Okay, Sania says all clear.
Thank you for that.
If anybody else wants me to stop and slow down, let me know.
Otherwise we will continue.
So the first thing that you want to check
is you're going to want to check what my status code is.
And Sergio and Felipe were very kind to share the status
codes with me.
I was just going to go and find one on the internet.
So I'm going to go with Sergio's one, which
is on the Mozilla Docs site.
Mozilla is a great--
MDN Docs is a great place to learn about web development.
They have all the requests there.
So you will notice that a lot of these requests are sometimes--
sorry, these status codes are often codes
that you will see when you're just browsing a website.
And you'll see something, 500 error code.
You can actually come here and you can see what's going on, what's broken.
So 400 is a bad request.
There was a problem with the request that you made.
Maybe you pass the wrong dates or whatever the case may be.
401, for example, is unauthorized and so and so and so it goes.
So the first thing you're going to want to do is you're going to want to check your status code.
And you're going to want to make sure that your status code is,
and I'm trying to see if I can find it in this page.
There's 200.
So 200 is your, it's okay.
Everything's good.
Nothing went wrong, we're happy, and you've received the data you need to receive.
Generally, what you can then do is you can use a function, which I'll share with you now.
Let me just open it up here in the documentation.
You can use a function called WP Remote Retrieve Response Code.
You can use that on the response that you receive from the request,
and that will return the error code itself.
sorry, I'm jumping around on my screen here.
You can literally do something like this.
You can say code equals wrong one.
Let me just copy it again. It's in my notes.
WP Remote Retieved Response Code,
and you pass it the data response from your request.
Now, if you happen to have come from another platform,
another CMS, maybe even a PHP framework,
maybe you've used something like an HTTP client,
a PHP, HTTP client like Guzzle or one of those.
A lot of this is built in for you.
So when you use the default methods there,
you can just call another method and get the response code back
quickly.
If you're building in a WordPress plugin,
you need to use some of these functions a little bit
manually yourself.
You'll notice in that class that I shared with you earlier,
some of this I've automated.
And when the response is made, I automatically
pull the code out and put it into a variable
so I can check it later, trying to not repeat myself
as I keep making these requests.
And so the first thing you might want to do-- and again,
there's no right or wrong way here.
But what you might want to do is you might need to check,
well, is the response code 200?
The other thing that you can do, though,
is you can do something like this.
And this is something that I've seen in projects,
and I recommend this as well.
You can use the-- sorry, let me just go--
let me move this thing.
It keeps jumping on my screen.
you can use this function called the isWPError function.
Now, what this will do is let's say you've called something wrong in your WordPress request area,
something's gone wrong somewhere, and it might return an error before it even tries to make
the request. Then you can use that and you can say, well, is there a data, an error?
So what I'm going to do, I'm going to just actually change these variables quickly.
I'm going to make this a little bit clearer.
So I'm not getting data back.
I'm getting a full response back.
So it's a response from the server,
which contains all that information
I showed you on the screen.
And one of the first things you might want to do,
you might want to say if is WP error response.
So if some WordPress error happened before the request
could even be made, maybe there was something
misconfigured somewhere, or who knows what,
then you can output some kind of message
and say there was an error on the site
or there was an error that happened somewhere or something.
And then you don't even have to worry about checking
for the code, because the code wouldn't have happened.
The status code wouldn't have even been returned,
because the request couldn't get made.
So that's the first thing I like to check.
Was there some kind of WordPress error
when I was trying to make this remote get request?
And then I might just do something like, say, echo
an internal WordPress error happened that prevented the request from being made or something along
those lines. However, your software situation requires it. Then once you've done that, then
it's a good idea to get the code. Because if there wasn't an error, it probably made the request
correctly. And whether the request response was good is up to whether the server sent it back or
not. So that's a good idea to do the code check. And then you could do something like this. You
You could say, OK, fine.
If-- and you would say maybe 200 is not equal to the code.
And I'm actually just going to do this as well.
I'm going to just return here because I don't
want it to continue after that.
So then you could say something like if the code was not equal
to 200, then again, you could say, echo, the request was made
but an HTTP error occurred.
And then you might also want to add the error code
to the message so that the person knows whichever happened
and they can then investigate further.
And I'm just going to return there.
And you might want to do more with that information.
I'm just seeing it's giving me an error here
and I'm trying to figure out why.
"Oh, this is an escaping function, that's why, okay.
"PHPCS has been very picky to me today."
So that's the next thing that you might wanna do.
You might wanna check, well, if there was an error,
sorry, if the code was 200,
or it wasn't 200, then an error happened.
Sorry, I'm getting myself confused here.
And the cool thing is then you can also do something
like this, you can say, you can do this,
you can say echo response,
and you can say get error message.
like that.
Is that right?
Yeah, it's giving me escaping function issues again.
So you can actually get the error message, if you remember,
we looked at that earlier.
Where was it? Yeah, you can get the message and then display that message to the user.
So that's another good thing to do, is actually show them what happened and why things went wrong.
So that's the next thing you could do.
Once you've done that, then you're probably pretty sure that things have gone right.
You've checked for WordPress errors.
WordPress errors didn't go wrong.
You've checked for response errors.
And if there were errors,
error codes were not 200, you've displayed that.
So now you can probably start working with this.
But you're probably not going to need the whole response.
You just need that body.
And WordPress has another function that you can use,
which specifically will get the body from the response.
So let me just get there quickly.
And we'll say retrieve body.
So WP Remote retrieve body will take any HTTP request response
object or a ratio, I say, and then retrieve the body from that.
So what we can do now is we can say, OK, fine.
The actual data that we want to work with--
and we know it's product data from the documentation.
So we can say product data equals WP Remote retrieve body
and then pass in that response.
I see there is a question, Elliot.
I will get to your question in a second.
I just want to finish this up so we can actually see it working.
And now we have that data.
And if we have a look at the data that we get over here,
we remember that, oh, yes, this is JSON.
So we're receiving JSON data.
So we might need to do something with that JSON
so that we can work with it.
And in WordPress Land, there is a JSON, or at least in PHP Land,
should I say, yeah, this is a PHP function, not a WordPress
function, silly boy.
So in PHP Land, there is a JSON decode function.
So JSON decode takes that JSON string and converts it
and returns it as, let me just check here,
it will return it as the relevant type.
You can set the second parameter associative,
will return an associative array,
when false it will return an object.
So if you don't specify that second parameter as true,
you're going to get an object back
and you're gonna have to use object notation
to export your data, which I will show you now.
So if we go back to the code, there is our product data.
In fact, that's not the product data I like.
That's just the body.
That's just the body which contains the JSON string.
The product data is actually the JSON decoded body.
So we would go product data equals JSON decode
and we decode the body.
So that's that.
And now we should expect that product data.
And I haven't tested any of this yet.
So this could go wrong and we'll fix it if we need to live.
But we would assume now that that's probably going
to be the product data.
It's going to be in an object.
So I'm gonna pop this into a div quickly.
I'm gonna update this to pop it into a div.
I will share the final code with you in the chat.
And then we might want to loop through this product data.
So we would say for each product data, not that one,
sorry folks, for each product data.
and we will say something like as product.
Let me move this up so if anybody wants to see this
on screen, they can.
There we go.
And then we can just loop through the product
and we can say, okay, fine, let's just start with the product.
Let's say, let's have a look at the documentation.
I can't remember what the fields were.
There it is.
So if we get all products, the output will be,
it'll be an ID, title, price, category.
So let's go with title and price for now.
So we will say product title,
and you'll see that I'm using the object notation,
which is a little arrow.
Let's wrap the title in some kind of HTML
so it makes sense when it displays,
otherwise it'll be all over the place.
Actually, maybe that should be a header tag
(laughs)
for correct semantic HTML.
Make it an H3, just for the sake of not being a paragraph.
And then I'll do the same for the price.
We'll pop that into a paragraph tag.
And we'll say product price.
And then we will close that.
All right.
And then that should give us the product title, the product
price in our page.
I'm going to leave that on screen.
Let's do a quick test and see if that did work.
So let's do a refresh here.
If it all went well, it should work.
And there we go.
We're getting the titles.
we're getting the prices for all the products from the API.
OK.
Elliot said, doesn't get error message
belong to the isWPError function?
Get error message.
So let me just confirm that quickly.
So what I'm going to do is I'm going to--
actually, Elliot, your question is timely,
because the next thing that I'm going to talk about
is how we would answer that.
So give me a second on that one if you don't mind.
There's something I want to show you.
And this is how I tend to develop with these things.
And then that'll help us answer that question.
So thank you for that question.
We'll dive into it in a sec.
Does anybody else have any questions around this code?
Let me share it in the chat in case anybody wants to copy it on their side,
so that they can try it out if they want to.
But essentially, as I said, you make your request,
you get a response back,
you're then going to check if the response had an error.
Someone says, "I've closed my H3 tags incorrectly.
Thank you for pointing that out."
PHP Storm is nice.
When I change the first one, it changes the second one.
VS Code doesn't do that for me.
So as I was saying, your first thing is you want to check,
was the response, was there an error, a WordPress error,
in relation to the response.
So something internal inside WordPress went wrong somewhere.
If not, get the response code and then test the response code.
If it was a 200, great.
Move on.
If it wasn't, maybe show an error to the user
and then get that error message.
We'll test that error message thing in a second, Elliot.
And then once that's passed, then you should be good to go.
And then you can say you can get the body,
because the body is usually going to be the data that you
need to work with.
And then depending on the body's contents, whether it is XML,
it's usually going to be some kind of string format, either
XML or JSON.
SOAP is essentially a format like an extended version of XML.
But it's going to be one of those or something--
it's not going to be like a full HTML response.
You're going to get that body back.
You're going to do whatever decoding you might need to do.
And then you could loop through that data
and display it on your page.
OK.
I'm going to grab a sip of water before we dive
to Elliot's question, sip of water, sip of coffee. Maybe I should have water. The coffee
might be making me fast. And then we won't move on.
So as I've mentioned to me that I've set this workshop for an hour and a half. And that's
because there's a lot to get through today. So I'm glad we have that extra 40 minutes.
If anybody needs me to slow down or stop or whatever, do let me know. But I'm going to
to continue along so that we can get through everything.
Okay, so Elliot's question was around,
isn't the get error message supposed to be on something else?
And this leads me into the next thing
that I wanted to share with you.
And that is debugging your responses.
So one way to do it is using that print R
that I showed you earlier and getting it on screen.
The problem with that is,
you then have to code that into your code,
then you have to show it on screen,
then you have to remove it or hide it
or whatever the case may be.
There are other ways to debug this information.
You can use things like Xdebug and those kind of tools.
But one of the simplest ways that I
found to do this kind of debugging--
and I'm sure Elliot will--
Zahirah is just going to resend the code.
Sure, let me do that quickly.
Elliot will-- I'm sure--
oh, wait, someone's already done it.
Thank you, Adrian.
Elliot will appreciate this-- is to use the WordPress debugging
log.
And I saw Elliot actually tweet the way
that I do my debug logs recently.
So thank you for sharing that with folks.
But if you go into your WP config file,
and some of you will have remembered
that I've done a session on debugging in WordPress before,
there is this WP debug constant
that you can set true or false.
The way I like to work with my debug log
is I can, in WordPress, you can define
whether to switch debugging on or off,
but you can also tell it to log any errors to a file
and not display those errors on the screen.
So I like to use that.
So I use the following.
I use defineWPDebugTrue, and I'll pop this in the chat
now as well.
I define WPDebugDisplay as false, meaning
don't show the errors on screen.
And then I define WPDebugLog, and I
define the path to a logs directory inside of my WordPress
install.
So I physically go and make that logs directory.
I will make it now here quickly.
And then the log file is debug dot, sorry.
And then I append the current date in this format, year,
month, and day, because I follow the year, month, day format,
not day, month, year, or month, day, year, whatever it is.
So I always put the year, then the month, and the day,
and then dot log at the end.
And what that will do is every day
that I start new development, it creates a new debug log file.
So it's a nice way of not letting your log file
become hugely big and crazy.
And when you're working today,
it's everything's in one today's file,
and then tomorrow it's a brand new file
and you can start fresh.
So that's what I use in my WP config
to enable logging to a file.
I make sure that folder's there
and I make sure this is set up past to that folder.
This path over here, I use a local Ubuntu virtual server.
So that's why the path is the path on the virtual server,
not on my local workstation.
So my local PC, so depending on how your environment is set up,
you might have to tweak that path.
If the path is on your local PC, you'll
have to put in whatever that path is.
If it's on a virtualized system, something like Docker, maybe
WPNow, one of those, you're going to have to set that.
This actually goes back to, I think,
it was Sergio's question about using WPNow.
I actually don't know how to set this up in WPNow
that you can enable the debug log in this way.
So this part might not work for you, Sergio.
I think it was Sergio.
So I apologize if this doesn't.
but the rest should work fine.
And then when you're working with your code,
you can use the PHP error log function.
So error log is basically a PHP function
that just logs files to whatever the defined log error log is.
In our case, it's that debug log file.
And you can use that printR function that I showed you earlier,
and then you can pass in whatever data you want,
be it an object, be it an array, be it a string, be it whatever,
as long as you pass in the second parameter of true.
And what that does is returns it as a string, which will then output to the log.
What you will also notice is that because we're doing it this way,
we don't have to worry about those pre-tags.
It'll be formatted nicely in the log file as well.
So that's what I'm going to do here.
I'm going to error log the response for this one,
so that we can then look at the response.
It'll be a copy of what we saw earlier,
but then we can see if there are any methods there.
What I'm also going to do is I'm going to do this.
And bear with me while I'm doing this.
Get class methods.
There's a PHP function called get class methods.
And you can pass it an object,
and it will return the methods for that object.
And that'll tell us whether or not this get error method exists on the response object.
So I'm going to make that true as well.
And then the other thing that you can do,
and I do like doing this,
is the array that I pass into the print R
is the first parameter.
I like to wrap that in an array,
and I like to give it an English,
or in my case English, because that's my language,
but a human-readable title.
So it's easy to find the content I'm looking at.
So what I will do typically is I will say
response object for this one.
I just give it a description of whatever
this data is that I'm passing it.
One sec folks.
For this one, I'm going to wrap this in,
And I'm going to say response object methods.
And then I will get the class methods,
which returns an array.
This is all just stuff that I've used over the years,
which is why I could remember it.
So I'm gonna pop that in there
and that will give me what I need.
All right.
So let's make this request again
and let's see what happens.
So I make the request again.
There was an error.
something wrong somewhere, which is fine.
Let's go and have a look at the log.
So if we go into the logs directory, there's nothing there.
So I've done something wrong in here.
It might be what I've done here.
So let me try this one.
Take that one out.
See if that one works.
There we go.
OK, so the second one failed.
That's fine.
We'll have a look at that in a second.
So let's have a look at that first log.
Oh, it's not, oh dear, it's not logging to the right place.
I have configured something incorrectly.
Oh, ha ha, wrong site.
This was copied from my other test site that I use.
So this site is LearnPress.
So let's do that.
So it's the LearnPress site.
Let me try that again.
Now we should get a log file.
There we go.
There's my debug log.
There is my response object.
You see that's how I give it a nice header.
So it's clear what I'm going to be working with.
Here is all this data that we saw earlier.
If you remember, we saw this all on the screen.
Here is the response object,
data_headers, status_response.
I just want to see if the methods are in here.
I don't think they are.
I want to get them from the object.
That was that. Let me see what's wrong with this one.
I was pretty sure class methods was an array.
Hang on. Wait, let me do this.
Let me do this.
Maybe it's not an object.
That could be why.
Maybe I can't get class methods on the object.
That might be why.
So let's see.
I've never done this before, so trying things live here.
Always fun, hey?
Okay, let's see what that does.
See if that gives me an error.
Yeah, that's probably the problem.
So now let's see what we get in the debug log.
We should get some kind of error about that.
Here we go.
Get class methods.
Here we go.
Must be an object or a valid class name.
So it's not returning it as an object,
so I can't get the class methods on that.
So let me-- so that means that very possibly this code,
as it has pointed out, doesn't work.
So let's test that.
So let's do this.
And then let's say, error log.
Let's just get the message.
Sorry, folks.
Pressing the wrong buttons here.
Let's just get the message return that is true.
And then I'm just going to wipe my debug log for now.
And I'm going to comment out this one
because I want to see what happens if I try and get
that error message.
There we go.
And let's do that.
Hm.
Oh, wait, wait, wait, wait, wait.
Yeah, so it looks like that get error message is incorrect.
I must have copied that response somewhere incorrectly.
So I apologize for that.
Elliot's point was correct.
It doesn't look like there's a get error message.
It must be a-- hang on.
Let me just have a look here.
Let's check the documentation.
So let's go to--
I can find my--
let's go get error message.
Oh, it's WP error get error message, single error message.
What I'm looking for is, okay.
So now I'm gonna do something that I don't often do.
I'm gonna start diving into the WP remote get function call.
And this is inside the HTTP class.
And I'm gonna search for get error message here.
No, there's no get error message there.
So let's go into that, that's the object there.
New, that's what I want, that's what I want.
Okay, now there is no get error.
Maybe it's get error.
No.
All right.
Let's see if the documentation for WP remote get
tells us how to check that error.
That's the response code,
that's the header, basic authentication.
There's nothing about checking an error.
So let's check remote get.
That'll return a response or error on failure.
Tree body, tree response code.
It looks like, yeah, it looks like that get error method
that I was using doesn't actually exist on the response.
Would only work, it says belongs on the WP error class,
would only work if remote get was an error.
So yes, good points on that one.
So let's go back and fix that.
So it was saying this would only work if it was an error.
so you wouldn't use a J.
That's where I went wrong.
It would be up here.
(laughs)
I used it in the wrong place.
Thank you for pointing that out, idiot.
So the error message I would get if there was an error,
and then I would be able to get the error.
Thank you, Elliot, for pointing that out.
I was using it in the wrong place.
Apologies, folks.
That's how that would work.
Okay, but the point that I was trying to make there
was if you can set up some way to debug your responses
debug your errors and look at them in logs.
It is a handy way to find out what's going on,
and then you can start diving into the code,
into the documentation of those things.
Awesome. Thank you to Elliot for pointing that out.
I'm just going to quickly scroll back through
the notes to see if there's anything that I need to check.
Elliot says, "Logging by date is useful to
isolate pinpoint reports areas."
Yes, scraping logs can be painful when
trying to find specific dates.
Adrian says, "Watching others troubleshoot is
actually quite educational.
I just panic when I get errors.
I do too, you can't see me panicking, but I am.
(laughs)
And then Edith pointed out about it belonging
to the error class, that will be 100% correct.
I had it in the wrong place.
Thank you, Edith.
I will update my notes about that.
Don't know where I copied that from.
Okay.
So that is how a request might work.
Sending a request to fetch data is very, very similar.
So let's have a look at the documentation on that one.
If we go back here, we can go to the posting data
to an external service.
And essentially it's the WP remote post function.
So I'm going to paste that into the chat.
I see Sergio says for debugging, I often use WP shell.
Yes, I love WP shell from WP CLI.
It's one of my favorites.
Felipe points out the documentation is clarifying
about what's returned exactly correct.
So thank you for sharing that there.
So with a post, you are making a request again to a URL.
And if we have a look at our documentation for Fake Store,
if we want to add a new product,
we will see it as a post method.
And then it requires a body, a body of information.
In this case, it's again, it's a JSON body.
And so we would pass in a title, a price, a description,
and all of those kinds of things.
So to make a post request is a simple case
of changing the function
and changing the data being sent.
So in my example here, I'm going to simply set that up
and then we can post that data.
So let's take that and I'll show you what something
like this might look like.
So here you would go WP remote post.
It happens to be, in this case,
it happens to be the same URL.
And this is often the case with web APIs.
Is it the same URL is used to make the fetch
and to send the data.
The only difference is the verb or the request method
that is being used is changed from a get to a post.
And in WordPress,
because you're using the built-in get or post function,
that verb is set up by default.
As Felipe pointed out,
there is also the WP remote request function,
which essentially remote get and remote post
are wrappers for the request function,
and the request function sets up the header,
sorry, the verb, be it get, post,
or whatever the case may be.
So to make a post request, you use WP Remote Post.
The other thing you often will need to do
is you will need to send some kind of data.
So you would need to set up some kind of data array usually.
In this case, according to the documentation,
what I'm seeing here--
let's go back to fake store--
is it is a JSON object that you need to send,
and it's titled products, et cetera, et cetera, et cetera.
Now, what's cool about the WordPress HTTP Request API
is that you don't have to take the array
and convert it into JSON.
The Request API will do that for you.
So all I have to do here is I have to set up an array.
Inside of the array, I set up the body item,
which is the body that I'm sending to the endpoint.
I create a new array, and then I can simply just start
passing in my fields.
So I can say title, and I can say my new product.
And then I can say price.
Let's go over here and say price.
It won't be my new product.
It'll be whatever the price is, and so on and so forth.
I'm not doing my arrays correctly here.
So let's do that property there.
And then let's do--
no, not that one.
No, that one.
Thank you.
It's not getting used to my keyboard, if you can believe it.
And so usually you would send--
have I done something?
There we go.
Usually you would send this as an array with body,
and then the array of data there.
And then you would pass this as arguments to the request.
So usually you would set up this array.
You could call it args or arguments,
whatever the case may be.
and then you would pass these arguments into your post
to then be able to create your data.
You can use similar checks.
So you can check if the response was an error or not.
You can check whether the status code was correct or not.
In this case, it says if an error happens.
In this case, it says, because this is a test API,
it says if you set an object like the code above,
it will return you an object with a new ID.
Nothing real will be inserted into the database.
If you want to access the new ID,
you will get a 404 error.
So all we should get back is an ID value from that response.
So we should be able to do the same kind of 200 code.
We should be able to do the same kind of body,
get remote body and the same.
Now this time we won't necessarily get product data.
We will probably just get some kind of data back.
So all I'm going to do here is I'm going to
pop that into there.
I'm gonna just clean that up quickly.
And then I'm just going to print r of the data,
just because I'm expecting it to be an ID.
We'll say true.
Actually, I don't need true there,
because it's inside of the PRE tags.
OK, so there we are setting up our post request.
We're setting up our body.
We're setting up our data to send in the body
as arguments to the request.
So let's see what happens.
OK, now we're getting critical errors,
'cause I've done something wrong.
So let's see what was logged in the debug log.
And it says, "Object of standard class
"could not be converted into string on line 67."
So let's have a look at that and see what that's telling me.
So, oh, 'cause I'm doing print, not printR.
Sorry, folks, there we go, printR.
You know why print came out?
I don't think I've ever used print in PHP land.
So let's see, there we go.
So there's my standard object.
So it returns the ID.
It happens to return the title and the price as well.
So I could then use that to check if I get the ID.
Yes, it was added and off I go.
And that is often as simple as it is can be
to send data to an API.
We'll dive into just now into some of the more advanced
things that you can do.
But really if you can master the GET request
and the POST request,
you can do most things with external APIs.
Okay, I see Felipe has posted a comment.
So I just wanna read that.
Sometimes the response might come with a 200 status code,
but an error message might come inside the JSON data returned.
It depends on the API.
Personally speaking, handling all the possible failures
coming from an HTTP request is always
the most challenging for me.
That's a very good point and one that I wanted to mention.
So now is a good time to talk about.
So first of all, I'm going to say this.
This is not necessarily my opinion,
but I've seen this in other spaces.
I've seen people talk about this in other spaces.
I've done this by accident, so I'm happy to admit it.
But sometimes when you're developing an API,
when you're developing an HTTP API,
so a way for folks to connect to your service
and retrieve your data, you might
be using some kind of boilerplate service
or some kind of scaffolded code.
And you scaffold your GET request, for example.
And so the framework that you're using or the tools
that you're using only expect you
to set a different response code if there's an error.
And so when you're writing your code, you forget to do that.
You forget to set the response code for an error.
And the default response code, if you don't specify one,
is 200.
So what happens is folks make requests.
An error happens.
The developer sets the error, but doesn't
set the correct response code.
And so what you end up with is a 200 response code,
meaning everything's okay,
but everything's actually not okay.
So it's a good idea, as Felipe's pointed out,
to get the 200 check, and I'm not doing this today
because I didn't wanna dive into that too much,
but to get the 200 check,
but also check if there's some kind of message.
So if we have a look at the WP remote retrieve functions
in WordPress land.
- Sorry to bother you.
Elliot has a question.
He's saying not sure if it's relevant for the workshop,
but his question is, are there any considerations
for rate limits in the context of external requests?
- Okay, I'll get to that when I'm done yet.
Thanks for pointing that out.
So if we have a look at,
there's response code,
WP remote retrieve response message.
So that is the method that you would call,
sorry, the function that you would call
on the response object to get,
If you remember, let me see if I've got that data still
in the debug log somewhere.
No, I don't have one right now.
But if you remember, I showed you in that array,
there was the response code, and then the message below that.
The response code was 200.
The message was OK.
It's a good idea to check both--
let me go back to the code--
to check both the code and the message,
because the message might include additional information.
So you could do something like this.
could say message equals WP Remote Retrieve.
Where is it now?
There we go.
And then you would pass-- again, you
would pass the response into that.
And then check the message.
And maybe what I've actually done in the past--
and I did this with the Seriously Simple podcasting
plugin that I showed you earlier--
Every time a request is made, I log the request,
the response, and I think the message.
Because sometimes when it goes well, but there's a problem,
then the message is useful information.
So yes, be aware that sometimes APIs do have that problem.
If you're working with an API that returns a 200 code,
but there's actually an error,
report that to the developers,
'cause I can almost guarantee you that's a bug on their side.
They really should be forcing the response code correctly.
And I know this because when we picked this up on our API,
I spent, I think a day and a half
going through every single request that we had
that didn't have an explicit response code.
And if it was an error response,
I was adding those response codes.
And I learned a lot about response codes that day.
It was just years and years ago.
So yes, sometimes it can happen and it's not right.
So be aware of being able to do that as well.
Okay, "Eddiot says, not sure if it's relevant
"to this workshop, but are there any considerations
for rate limits in the context for external requests?
That's a good question.
And that actually goes into the next section of this workshop.
So I'm glad you brought it up.
If you have a look, let's go back to the documentation.
The very next item is called performance
in the documentation.
So let me share that with you.
And in that section on performance,
the developer documentation talks about not only
your application has to make a request, your application has to wait for the server to respond,
but also there might be rate limits on the API that you're using. For those of you who don't
know what a rate limit is, sometimes it'll have like you can only make a request 100 times in a
minute or whatever the case may be. So that's why it's a good idea to cache your responses,
especially if it's something that you're not going to need every time you make the request.
you're not going to need the most up-to-date version of that data.
It is unfortunately outside of the scope of this workshop,
but I am planning on doing a workshop on using the transient API or the transient API,
if you speak with an American accent.
And this is a way that you can cache-- I see AJ laughing at me now.
I see this is a way in WordPress that you can cache that data.
So you can, when you're paid-- let's say you're connecting to an external service to low products
for some kind of service that you're running that's connecting to maybe Amazon or something.
Those products are not going to change a lot. So maybe you cache that request once every hour or
whatever the case may be, and you can use the Transience API to do that. So that is something
to consider. Thank you for pointing that out, Elliot. We will do a session on the Transience API
and figuring out how that works, but unfortunately we don't have time for that today. Okay. Are there
any other questions before we move on.
There's a couple of advanced things I want to show you.
I always find the downside to these workshops
is I can't show you everything.
I can't show you every use case, everything to think about.
It's really just introduction to these things.
But hopefully, this starts giving you
an idea of how these things can work,
so that if you need to make these requests,
you know where to start looking.
All right.
The last thing I want to cover today
is just some advanced topics.
So the first thing that I want to mention
is that you can make requests with using different methods.
So if you need to make a delete request,
and the API requires you to post with a delete method,
you can use the args array, pass in the method as delete,
and then you use that WP remote request function
that I think was Felipe shared earlier.
So WordPress doesn't have a built-in WP remote delete one
or a WP remote patch or update.
So then you would specify the method that way,
and you would do it that way.
Generally, your get and your post are enough.
Some APIs will allow you to update using post
as long as you pass the ID in.
Some will require you to use specifically a put or a patch
verb or method.
So then you can specify those by using WPROMITE request
and then specifying the method in that args array.
You also have a whole--
There is a question from [INAUDIBLE]
from the previous topic.
any person doing asynchronous API calls or when doing dozens at a time.
Okay, I'll come back to that once we've covered this.
There are also additional options in the arguments parameter that you can set.
If you go to the WPHDP request method documentation, you can see all those things there.
What I tend to prefer to do though, is I go into the actual WP_HDP class
file in my local WordPress install.
Then all the constants that you can set all
there and all the different options.
You'll see in this, here's the request method,
and then here are the defaults.
I can set the method, I can set timeouts.
In other words, how long does it take
before it times out and stops the request?
You can do things like redirection,
HTTP version, all kinds of other fun things.
We don't have enough time for that today,
but if you need to specify any of
those over and above the defaults,
then you can specify them there.
You can also specify and receive headers.
Sometimes, and here we talk about rate limiting.
So often, this gets back to Elliot's question,
often APIs will send you in the header
the x rate limit limits, the number of requests
allowed in a time period, and the number
of available remaining requests.
So you can use that to check whether you are rate limited
or not.
You can use the WP remote head function
to get those header values and then be able to read those values from the response
and see how things are working there. So you'll see there's an example at the bottom here.
So in this one, the header's, the x rate limit remaining on this one is 4982.
And so if I do a few more, I've probably got some more time to continue along there.
Okay, that's everything under performance. Let's look at Sergio's request. Any thoughts on doing
asynchronous API calls for when doing dozens at a time.
Okay, so that's a whole separate topic.
I have built projects that do asynchronous API calls.
I have generally set them up using something similar
to the WooCommerce action scheduler.
That's what I used at the time.
It's basically like a bigger version of Cron, if you will,
WP-chron, it's a way that you can schedule tasks to run in the background. That's how I've done
sort of asynchronous calls. I know in PHP there is something called, I think it's ReactPHP or
something that allows you to do asynchronous calls. I've never used that before. But yes,
it's definitely something that is possible in PHP. The other option is you can do it in JavaScript.
JavaScript allows asynchronous calls, so you can do that one. So there are definitely options
out there, you kind of need to find the one that suits your project and what you need.
So here's a fun one, "WP remote get remote head, WordPress orgs, plugin, FakerPress headers,
get last modified." Cool. So will that get you the last modified date of that plugin?
That's what I think it looks like. Awesome. Cool. And that's the cool thing about HTTP.
You can make a WP remote get request to any URL. It doesn't have to be an API. It could be a website.
Let me show you that. This is fun. I think this is brilliant. So I'm going to show you that.
So let's go back into the plugin, if you've never seen this before. And we're going to -- I'm going
to do this. I'm going to WP remote get. And I'm going to get my homepage with my blog, just for
fun. So we're going to go to JonathanBosinger.com and we're not going to pass in any arguments
and then let's get the headers as well, why not? So let's get the headers.
I think wp-remote-head, let me just see here.
So I think I just need to pass in the URL as the URL. Let's do that. So wp-remote-head,
let's do that, and let's do that. And I'm just going to just assume everything works.
And I'm going to just log that to the debug log file.
I hope nobody finds this boring, but I've never
haven't done this in a while, so why not?
Error log response, so I need to print r.
And I need to pass it.
True.
And you can do this on your own sites if you want to.
It's a huge amount of fun, I think.
OK, let's do that.
And let's-- Zoom has decided to bother me on screen again,
so let's move it out of the way.
And let's do the request.
And then let's see what is sitting in the debug.
In fact, let me clear out the debug log
because there were some errors.
Let me do it again.
And then let's check.
And there we go.
There are the headers for my website.
It is running on Nginx.
That is correct.
Today's date, content type, it's HTML.
I expect it to be HTML.
It has something called strict transport security
set at exception coding and cookies.
It's hosted at Pressable.
That is correct.
It has the xclack's overhead GNU terry-pratchett header.
If you're a terry-pratchett fan, you probably
know what that's about.
And then it has some links to my JSON
and various other things.
And I can use that to get the data.
You can make requests to websites like that.
A lot of scraper tools use HTTP requests in this way
to scrape data.
Obviously, you'd have to deal with rate limiting.
I'm not recommending that you do scraping,
but that is what these tools use.
So you can build all kinds of interesting and fun
things if you know how to request that data.
All right.
That's kind of my bit for today.
I just wanted to share one or two other things with you.
The one is postman.com.
I have mentioned this in previous workshops.
If you are working with APIs, postman is a great way to test them,
to test your API requests.
When I was, I'm going to open up postman on my machine very quickly
and share postman in the link, in the chat.
You will see when I was testing Fakestore, the first thing I did was I loaded it up in Postman and I ran some requests.
Because I wanted to make sure that it worked, make sure that it got me responses.
So it's a great way to test your APIs before you start writing your code and making sure things work.
And I do recommend using it as a tool.
Elliot says Postman is essential for APIs, absolutely.
There are other tools out there.
There are a couple of other open source tools.
I do mention them in the WP REST API tutorials.
I can't remember them offhand now,
but my personal preference is Postman.
I just find it to be very easy to use.
Elliot says, "I thought I was a three to four.
I now realize I'm a three.
I was a three, I'm now a 3.5.
I've always learned something new watching others.
Thank you so much."
Well, don't thank me,
'cause some of the stuff came from other folks.
So thank you to Sergio, Felipe,
and other folks who've been sharing links.
I love receiving information from folks.
So if you're ever in one of my workshops
and you have these kind of links, please do share them.
Because that's how we all learn together.
These online workshops are meant to be
learn together sessions.
We used to call them social learning spaces.
Because the idea was that they were not
meant to be single presenter presentation.
They were meant to be learning together presentations.
So please feel free to bring these links to these workshops.
I definitely enjoy learning from you all.
And so we all learn together and we all make each other better.
All right, so Jess says, "Insomnia is open source."
Yes, I've had a few.
Do you mean that?
Oh, yeah, sorry, I misunderstood you there.
I thought you meant open source means you're
up late at night investigating things.
Insomnia API tool.
Let's find that.
There we go, Insomnia risk,
collaborative API development platform.
So that's another one that folks can check out.
Thank you for sharing that.
But I think there's more truth about open source being
something that keeps you awake at night as well.
So there we go.
Awesome.
Folks, thank you so much.
That was fun.
I loved diving into all of that.
As I say, it is a very broad topic.
We can't cover everything.
There's so much more that you can go into,
but hopefully it was interesting
and hopefully it's kind of showing you
how these things work in WordPress land.
If you ever need to interact with or integrate
in external API, now at least you know where to get started.
I thank you all for your time.
I thank you all for joining me today
and sharing your knowledge with me.
I hope you have a wonderful Thursday
and a wonderful rest of your weekend weekend.
And I'll see you next week.
Bye-bye.
[END PLAYBACK]
Huh?