Rendering External API Data in WordPress Blocks on the Back End
The thing is, we accomplished this in a way that prevents us from seeing the data in the WordPress Block Editor. In other words, we can insert the block on a page but we get no preview of it. We only get to see the block when it’s published.
Save functions of the block plugin.
Save function is where we’re hanging out today. We can create interactive components on the front-end, but for that we need to manually include and access them outside the
Save function in a file like we did in the last article.
So, I am going to cover the same ground we did in the last article, but this time you can see the preview in the Block Editor before you publish it to the front end.
I intentionally left out any explanations about the
edit function’s props in the last article because that would have taken the focus off of the main point, the rendering.
If we log the
props object to the console, it returns a list of WordPress functions and variables related to our block:
We only need the
attributes object and the
setAttributes function which I am going to destructure from the
props object in my code. In the last article, I had modified RapidAPI’s code so that I can store the API data through
setAttributes(). Props are only readable, so we are unable to modify them directly.
Block props are similar to state variables and
setState in React, but React works on the client side and
setAttributes() is used to store the attributes permanently in the WordPress database after saving the post. So, what we need to do is save them to
attributes.data and then call that as the initial value for the
I am going to copy-paste the HTML code that we used in
This time, I have also not wrapped the code inside
useEffect() but inside a function that is called only when clicking on a button so that we have a live preview of the fetched data. I have used a state variable called
apiData to render the league table conditionally. So, once the button is clicked and the data is fetched, I am setting
apiData to the new data inside the
fetchData() and there is a rerender with the HTML of the football rankings table available.
You will notice that once the post is saved and the page is refreshed, the league table is gone. That is because we are using an empty state (
apiData‘s initial value. When the post saves, the attributes are saved to the
attributes.data object and we call it as the initial value for the
useState() variable like this:
We are going to do almost the same exact thing with the
save function, but modify it a little bit. For example, there’s no need for the “Fetch data” button on the front end, and the
apiData state variable is also unnecessary because we are already checking it in the
edit function. But we do need a random
apiData variable that checks for
attributes.data to conditionally render the JSX or else it will throw undefined errors and the Block Editor UI will go blank.
If you are modifying the
save function after a block is already present in the Block Editor, it would show an error like this:
That is because the markup in the saved content is different from the markup in our new
save function. Since we are in development mode, it is easier to remove the bock from the current page and re-insert it as a new block — that way, the updated code is used instead and things are back in sync.
This situation of removing it and adding it again can be avoided if we had used the
render_callback method since the output is dynamic and controlled by PHP instead of the save function. So each method has it’s own advantages and disadvantages.
Regarding the styling, it is going to be almost the same thing we looked at in the last article, but with some minor changes which I have explained in the comments. I’m merely providing the full styles here since this is only a proof of concept rather than something you want to copy-paste (unless you really do need a block for showing football rankings styled just like this). And note that I’m still using SCSS that compiles to CSS on build.
We add this to
src/style.scss which takes care of the styling in both the editor and the frontend. I will not be able to share the demo URL since it would require editor access but I have a video recorded for you to see the demo:
Pretty neat, right? Now we have a fully functioning block that not only renders on the front end, but also fetches API data and renders right there in the Block Editor — with a refresh button to boot!
If you need help creating a digital marketing strategy for your business, don’t hesitate to contact one of Digidude’s consultants.