Expose Gutenberg Blocks to the REST API with the wp-rest-blocks Plugin

WordPress>=5.5.3

Share this video with your friends

Published 2 years ago

Updated 2 years ago

We will expose the Gutenberg blocks to the REST API. Rather than having a single content blob, we now have the content split into blocks on the API. We can get accompanying data from each block and have more control when we render on the frontend.

This will be done by installing the wp-rest-blocks plugin. The catch here is that it isn't available in the WordPress plugin directory. We will need to download a zip from the wp-rest-blocks GitHub to then upload and activate in WordPress.

Course

WordPress as a Headless Content Management System (CMS) and GraphQL API

Instructor: [0:00] With Gutenberg, we got awesome blocks, but not a very helpful output when it rendered to the database. We're going to add a plugin that's going to help with this. The plugins called WP REST blocks, WordPress REST blocks. What becomes clear is this plugin isn't available on the store.

[0:18] This is a choice that some plugin developers make. They don't make it available in the WordPress directory. Instead, we have to install it in a different way. Rather than going to the plugin store, I'm going to go to the get repo for this plugin, WP REST blocks. We're going to download this code as a zip file.

[0:37] Back here in our plugins adding new, we're going to click on Upload plugin. We're going to choose that zip file, which we've just downloaded, and we'll install it. It's moving the files from that zip file into our file system, which is in Sawyer. Then, we activate our plugin. Plugin activate it.

[0:55] There's no obvious changes to our UI, but let's see how our REST API has changed. Remember before, we had this content blob, and excerpt, and we had some other pieces. Let's see what happens now when we created the same API endpoint. We've got our rendered, our excerpt, but we also get the blocks. You can see I had a core image block.

[1:13] I've got the URL for the image. I've got the alignment for the image, the Alt Text image. I get all this information that was captured in this HTML, but I get it as props or attributes that I can use in a headless way. For pull quotes, I can see, "Oh, here are the attributes that I'm likely to get for a calendar."

[1:31] Well, there aren't very many for that one. You can see the difference here is that I know this identifies itself as a calendar block, so I know, they're using a calendar. I might style that in a particular way, or do something specific with that, swap it out for a different type of calendar, get some information that might look different from that.

[1:52] This creates new opportunities for us. Rather than having one big blob of text, we can see that we have a page that's made up of blocks. We can treat each of these blocks that make up this page. We can expect certain things to be true of them. For each block, we can see we've got the name of the block, attributes associated with the block, and innerHTML.

[2:18] We could ignore the innerHTML, and use these attributes to build up the content for an image. You can see, actually there's nothing in the innerHTML that we couldn't create ourselves, the attributes. For this one however, for the pull quote, we've got some attributes included here, but the actual text hasn't been extracted as data. The text is in line.

[2:42] Not a perfect experience, but we're adding these things in in the UI that can then be picked up headlessly and impact prosthetic or headless build.

Kevin Cunninghaminstructor

~ a month ago

There are two points where this plugin install becomes challenging in later versions of WordPress.

In version 0.5.0 of the plugin and 6.0.1 of WordPress, I've had to do two more steps.

I've used Local to open a Site Shell and in there gone to the plugin's directory. Within the directory, I've ran composer install which installs dependencies that used to be shipped with the code.
I've had to edit the code in src/posts.php. When I installed the plugin, the blocks no longer rendered in the editor. By changing what the new REST API field is called, from blocks to blocksData, the editor rendered the blocks correctly and the data is available on the API. The updated code looks like this:

	register_rest_field(
		$types,
		'blocksData',
		[
			'get_callback'    => __NAMESPACE__ . '\\blocks_get_callback',
			'update_callback' => null,
			'schema'          => [
				'description' => __( 'Blocks.', 'wp-rest-blocks' ),
				'type'        => 'object',
				'context'     => [ 'embed', 'view', 'edit' ],
				'readonly'    => true,
			],
		]
	);

The creator and maintainer of this plugin is a core WP maintainer and I've reached out to them to see if there is a less "hacky" fix. I'll hold off until I hear from them and will upload a supplementary or updated video to cover this.