spacedmonkey / wp-rest-blocks

Add gutenberg blocks data into post / page / widget REST API endpoints.

REST API blocks

Contributors: spacedmonkey Donate link: https://github.com/sponsors/spacedmonkey Tags: blocks, gutenberg, api, wp-json, rest-api Requires at least: 5.5 Tested up to: 6.5 Requires PHP: 7.0.0 Stable tag: 1.0.2 License: GPLv3 or later License URI: https://www.gnu.org/licenses/gpl-3.0.en.html

Add gutenberg blocks data into the post / page REST API endpoints.

Description

A simple plugin to add block data in json format into the rest api. Once installed, there will be two new fields added to the rest api, has_blocks and blocks. For example output.

"has_blocks": true,
"block_data": [
  {
	"blockName": "core/image",
	"attrs": {
	  "url": "https://www.spacedmonkey.com/wp-content/uploads/2018/12/test-image.jpg",
	  "alt": "Terminal de aeropuerto",
	  "caption": "fsfsdfdsfdssfd",
	  "href": "https://www.spacedmonkey.com/test-image",
	  "rel": "noreferrer noopener",
	  "linkClass": "jonny-123",
	  "linkTarget": "_blank",
	  "id": 147355,
	  "width": 582,
	  "height": 327,
	  "linkDestination": "attachment"
	},
	"innerBlocks": [
	],
	"innerHTML": "\n<figure class=\"wp-block-image is-resized\"><a class=\"jonny-123\" href=\"https://www.spacedmonkey.com/test-image\" target=\"_blank\" rel=\"noreferrer noopener\"><img src=\"https://www.spacedmonkey.com/wp-content/uploads/2018/12/test-image.jpg\" alt=\"Terminal de aeropuerto\" class=\"wp-image-147355\" width=\"582\" height=\"327\"/></a><figcaption>fsfsdfdsfdssfd</figcaption></figure>\n",
	"innerContent": [
	  "\n<figure class=\"wp-block-image is-resized\"><a class=\"jonny-123\" href=\"https://www.spacedmonkey.com/test-image\" target=\"_blank\" rel=\"noreferrer noopener\"><img src=\"https://www.spacedmonkey.com/wp-content/uploads/2018/12/test-image.jpg\" alt=\"Terminal de aeropuerto\" class=\"wp-image-147355\" width=\"582\" height=\"327\"/></a><figcaption>fsfsdfdsfdssfd</figcaption></figure>\n"
	],
	"rendered": "\n<figure class=\"wp-block-image is-resized\"><a class=\"jonny-123\" href=\"https://www.spacedmonkey.com/test-image\" target=\"_blank\" rel=\"noreferrer noopener\"><img src=\"https://www.spacedmonkey.com/wp-content/uploads/2018/12/test-image.jpg\" alt=\"Terminal de aeropuerto\" class=\"wp-image-147355\" width=\"582\" height=\"327\"/></a><figcaption>fsfsdfdsfdssfd</figcaption></figure>\n"
  }
],

Technical Notes

• Requires PHP 5.6+.
• Requires WordPress 5.5+.
• Issues and Pull requests welcome on the GitHub repository: https://github.com/spacedmonkey/wp-rest-blocks

Installation

Using The WordPress Dashboard

1. Navigate to the 'Add New' in the plugins dashboard
2. Search for 'wp-rest-blocks'
3. Click 'Install Now'
4. Activate the plugin on the Plugin dashboard

Uploading in WordPress Dashboard

1. Navigate to the 'Add New' in the plugins dashboard
2. Navigate to the 'Upload' area
3. Select wp-rest-blocks.zip from your computer
4. Click 'Install Now'
5. Activate the plugin in the Plugin dashboard

Using FTP

1. Download wp-rest-blocks.zip
2. Extract the wp-rest-blocks directory to your computer
3. Upload the wp-rest-blocks directory to the /wp-content/plugins/ directory
4. Activate the plugin in the Plugin dashboard

Screenshots

1. Add fields to the rest api.

Changelog

1.0.2

• Fix issue with WordPress 6.5
• Update coding standards to WP coding standards 3.1.0
• Mark tested up to WP 6.5

1.0.1

• Update coding standards to WP coding standards 3.0.1
• Mark tested up to WP 6.4

1.0.0

Breaking change! The field in the REST API is changed from blocks to block_data.

0.5.0

• Add support for new post types added in WordPress 5.9.

0.4.0

• Added support for block based widget, added in WordPress 5.8. Block data is added to the /wp/v2/widgets endpoint.

0.3.2

• Update translations

0.3.1

• Hot fix.

0.3.0

• Improve support for block that have attributes that use query source type.
• Improve error handling for those that install this plugin without using composer.

0.2.1

• Update dependency.

0.2.0

• Breaking change. Field names have changed and required WordPress 5.5+

0.1.0

• First version.

wp-rest-blocks's Issues

pQuery deprecated in PHP 8.x

There is an "issue" with pQuery being deprecated in PHP 8.1.
Since the package hasn't been updated since 2016, maybe one could consider to replace pQuery with something which experiences updates regularly. I found DiDom for that case, which could be nice to work with instead.

Actually the issue is only deprecated warnings in Wordpress, though.

core/pullquote: `mainColor` is only used if `className = "is-style-solid-color"` and `customTextColor` is not used

Description

When setting the the "Main Color" of a core/pullquote-block instance in the editor by choosing a color of the color palette the mainColor attribute provided by the restAPI is not populated as expected:

It is only used if className = "is-style-solid-color" and customTextColor is not used. Otherwise the attribute customMainColor is used and populated with the hex-value of the chosen palette color.

Since the information is provided by the customMainColor attribute this is not a severe problem, but still seems inconsisent.

Examples

Not as expected: restAPI result for a core/pullquote block with "Style" set to "Default" and "Main Color" set to a palette preset with the slug "primary":

show result

{
  "blockName": "core/pullquote",
  "attrs": {
    "customMainColor": "#00aaad",
    "className": "has-background is-style-default",
    "value": "<p>is-style-default</p><cite>main color by Block Color Palettes</cite>",
    "citation": "main color by Block Color Palettes",
    "mainColor": "",
    "textColor": "",
    "customTextColor": "",
    "align": "",
    "anchor": ""
  },

As expected: restAPI result for a core/pullquote block with "Style" set to "Solid Color" and "Main Color" set to a palette preset with the slug primary:

show result

{
  "blockName": "core/pullquote",
  "attrs": {
    "mainColor": "primary",
    "className": "has-background is-style-solid-color",
    "value": "<p>is-style-solid-color</p><cite>main color by Block Color Palettes</cite>",
    "citation": "main color by Block Color Palettes",
    "customMainColor": "",
    "textColor": "",
    "customTextColor": "",
    "align": "",
    "anchor": ""
  },

As expected: restAPI result for a core/pullquote block with "Style" set to "Solid Color", "Main Color" set to a palette preset with the slug "primary" and "Text Color" set to a palette preset with the slug secondary:

show result

{
  "blockName": "core/pullquote",
  "attrs": {
    "mainColor": "primary",
    "textColor": "secondary",
    "className": "has-background is-style-solid-color",
    "value": "<p>is-style-solid-color</p><cite>main color and text color by Block Color Palettes</cite>",
    "citation": "main color and text color by Block Color Palettes",
    "customMainColor": "",
    "customTextColor": "",
    "align": "",
    "anchor": ""
},

Not as expected: restAPI result for a core/pullquote block with "Style" set to "Solid Color", "Main Color" set to a palette preset with the slug "primary" and "Text Color" set to a custom color with the hex code #0008ff:

show result

{
  "blockName": "core/pullquote",
  "attrs": {
    "customMainColor": "#00aaad",
    "customTextColor": "#0008ff",
    "className": "has-background is-style-solid-color",
    "value": "<p>is-style-solid-color</p><cite>main color by Block COlor Palettes and text Color Custom</cite>",
    "citation": "main color by Block COlor Palettes and text Color Custom",
    "mainColor": "",
    "textColor": "",
    "align": "",
    "anchor": ""
  },

Expected Behaviour

When setting the "Main Color" of a core/pullquote-block instance in the editor by choosing a color of the color palette, the attribute mainColor should be populated with the slug of the chosen palette color, no matter which other attributes are set for the block instance.

Incorrect core/embed block rendered property

Version

Wordpress 5.8.1

Problem

Core/embed block rendered property is not consistent with the regular PHP output as WP_Embed class is not run on the content.

Expected rendered block content (PHP)

\n<figure class=\"wp-block-embed is-type-video is-provider-youtube wp-block-embed-youtube wp-embed-aspect-4-3 wp-has-aspect-ratio\"><div class=\"wp-block-embed__wrapper\">\n<iframe title=\"Ed Sheeran, Martin Garrix, Kygo, Dua Lipa, Avicii, The Chainsmokers Style - Feeling Me #78\" width=\"1333\" height=\"1000\" src=\"https://www.youtube.com/embed/ssYbrK0eRZw?feature=oembed\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture\" allowfullscreen></iframe>\n</div></figure>\n

API rendered block content

\n<figure class=\"wp-block-embed is-type-video is-provider-youtube wp-block-embed-youtube wp-embed-aspect-4-3 wp-has-aspect-ratio\"><div class=\"wp-block-embed__wrapper\">\nhttps://www.youtube.com/watch?v=ssYbrK0eRZw\n</div></figure>\

Proposed solution

Either run the_content filter, which might be anyway a good idea in order to get a rendered content as close as possible from the PHP rendering, or use:

global $wp_embed;
$block['rendered'] = $wp_embed->autoembed( $block['rendered'] );

Great job on the plugin, many thanks!

Block added to revisions endpoint

Hey! First, thanks for this awesome little library! Real easy to follow along in the code as well 👏
I'm just wondering if you know if it is possible to also add the blocks data to the revisions endpoints (/wp/v2/<post_type>/revisions/<id>)?

Add to Wordpress.org/wpackagist.org

Please add the package to Wordpress.org/wpackagist.org. Right now it's a PITA to deal with Github API limitations when installing/updating from composer.

Add block data to widgets endpoint

WordPress add block support to widget areas. Along with a widget endpoint. Lets refactor the code to make easier to add this add to the widget endpoint.

Support WooCommerce Blocks

Hi, Any plans to support Woo blocks? I guess you may have to do them on a case by case basis?

Use block_version field instead of custom has_blocks field

In WordPress core there's a content.block_version field.

Instead of adding its own has_blocks field, the plugin could just make sure content.block_version is always shown, and not just in edit context.

WP 5.9.1 Gutenberg Error

Following this issue : #31

Gutenberg is not working well when the plugin is activated, there is some JS errors and the blocks are not loading at all within Gutenberg. This post here have some blocks and content but they are not loading :

The same post when deactivating the plugin :

Can you help ?

Support for re-usable blocks

Would it be possible to add support for re-usable blocks?

Re-usable blocks (renamed to "synced patterns") are basically the core/block component.

All that this component does is referencing to another to a block, including its data.

There already exists an API endpoint to access this references e.e.g /wp-json/wp/v2/blocks/83, but it requires authentication to access it.

So it would be really sweet if this plugin automatically fills in the reusable block data instead of just the referencing ID. Especially when you're using this plugin for headless WordPress.

Screenshot of the re-usable block data when using this plugin below:

When using a WYSIWYG field in ACF blocks, it doesn't auto add P tags

I've uploaded a screenshot above. When using a WYSIWIG field in ACF blocks, it doesn't seem to add P tags automatically after you press a newline.

I think WordPress handles auto-adding paragraphs in PHP by using a WordPress filter.

Would it be possible to support that? I think a lot of people use the WYSIWYG field inside ACF blocks to insert long text. But it's difficult to format in a front-end when there are no paragraphs.

I think the filter is called wpautop. See here: https://developer.wordpress.org/reference/functions/wpautop/

Other than that nice work with this plugin, this should be in core for sure. You're helping out a lot of folks who are using headless WordPress with Gutenberg as the editor. 🙂

`core/table` block not populating block attributes `head`, `body` and `foot` on rest API

Version

Wordpress 5.7.2

Problem

When using the core/table block on a post and filling it with data as well as enabling header and footer rows and saving the rest api does not fill the corresponding block attributes properties with data, e.g.:

{
        "blockName": "core/table",
        "attrs": {
          "className": "is-style-stripes",
          "hasFixedLayout": false,
          "caption": "Table Caption",
          "head": [],
          "body": [],
          "foot": [],
          "anchor": ""
        },
        "innerBlocks": [],
        "innerHTML": "\n<figure class=\"wp-block-table is-style-stripes\"><table><thead><tr><th>Header 1</th><th class=\"has-text-align-left\" data-align=\"left\">Header 2</th><th>Header 3</th><th>Header 4</th></tr></thead><tbody><tr><td>First Cell</td>...",
        "innerContent": [
          "\n<figure class=\"wp-block-table is-style-stripes\"><table><thead><tr><th>Header 1</th><th class=\"has-text-align-left\" data-align=\"left\">Header 2</th><th>Header 3</th><th>Header 4</th></tr></thead><tbody><tr><td>First Cell</td>..."
        ],
        "rendered": "\n<figure class=\"wp-block-table is-style-stripes\"><table><thead><tr><th>Header 1</th><th class=\"has-text-align-left\" data-align=\"left\">Header 2</th><th>Header 3</th><th>Header 4</th></tr></thead><tbody><tr><td>First Cell</td>..."
      },

I would expect the fields attrs.head, attrs.body, attrs.foot to be filled with data of the corresponding cells. Or am I wrong here?

---

By the way, I am using the plugin to expose the blocks of a post/page to a nuxt frontend and render each block as a vue component. So far it works pretty good, thanks for making this!

Wordpress 6.5 Incompatibility: text and content fields are null

Starting with WP 6.5, the fields text and content, which I would previously rely on to render Buttons and paragraphs/headings respectively, are now returned with a value of null instead of the string with their value.
Not sure if its within the scope of this extension since looking at the code, it seems like these fields don't seem to be explicitely processed by it.

Plugin breaks on block editor WordPress 5.9 RC

Hey! I'm testing out the latest version of WP, 5.9 on a small project. And right now it seems like this plugin breaks the block editor. This plugin seems to prevent rendering post content in the editor at all.

I think the issue is naming the field in the api blocks. Because if I rename the field to something different the editor works as expected again. I haven't been able to find the real issue in the gutenberg code. But I'm guessing that they somehow populate the blocks property in the code. But when it is already set initially they don't touch it. I'm not sure but will keep digging deeper.

Sync patterns inner blocks are empty

Solved in PR #86

Editing broken with plugin activated

Blank (white) page on post edit.

Wordpress 5.7.2

Move blocks data to content field

As suggested on Slack, it might make more sense to add this to the content field next to raw and rendered. content has been designed as an array from the beginning to allow extensions in such a way.

Support for ACF image field return format

Hi!

When creating an image field with ACF, wp-rest-blocks does not seem to respect the chosen return format in the ACF field settings.
When I choose "Image URL" or "Image Array", it still returns Image ID in the API.

Chosen settings for the field:

Output in the API:

Not even sure if wp-rest-blocks should respect those settings or is it the responsibility of the ACF plugin instead?

Installation using composer

Hi! What's the procedure installing this plugin from composer.json? How should the require entry look in a project that makes use of the plugin?

Thanks!

Possible to use for a custom endpoint?

Thanks for the plugin again!

I have a custom endpoint which i register with register_rest_route and i tried to do something like this:

use WP_REST_Blocks\Data;

add_action( 
  'rest_api_init', 
  function() {

    register_rest_route( 
      'mytheme/v1',
      '/page-template/(?P<filename>[a-zA-Z0-9-]+)',
      [
        'methods'  => 'GET',
        'callback' => 'mytheme_rest_add_page_template_endpoint',
        'permission_callback' => '__return_true',
      ]
    );

  }
);


function mytheme_rest_add_page_template_endpoint( $data ) {
  $page = mytheme_get_page_by_custom_template( $data['filename'] . '.php' );

  if ( empty( $page ) ) {
    return null;
  }
  $page->blocks = WP_REST_Blocks::blocks_get_callback( $page );

  return $page;
}

but it didn't work, got a system error.

What would be the right way to extend a custom endpoint with the block definitions that the plugin generates, given a post/page object?