You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a self-hosted site has a reusable block that contains a self-reference, it produces a bad response on every request to the reusable blocks endpoint (v2/blocks path), breaking the reusable block functionality.
This is reproducible on self-hosted sites with and without Jetpack, although the error response is different.
Edit the reusable block, add the same reusable block as part of the content and save it
Add the reusable block to a post/page
Edit the post/page in the mobile app
Check the response of requests to /wp-json/wp/v2/blocks and observe that the data is not JSON format
Here I copied an example of one:
Request response
<br />
<b>Warning</b>: Could not render Reusable Block <strong>RB 1</strong>: blocks cannot be rendered inside themselves. in <b>/srv/users/<USER>/apps/<USER>/public/wp-includes/blocks/block.php</b> on line <b>35</b><br />
<br />
<b>Warning</b>: Cannot modify header information - headers already sent by (output started at /srv/users/<USER>/apps/<USER>/public/wp-includes/blocks/block.php:35) in <b>/srv/users/<USER>/apps/<USER>/public/wp-includes/rest-api/class-wp-rest-server.php</b> on line <b>1642</b><br />
<br />
<b>Warning</b>: Cannot modify header information - headers already sent by (output started at /srv/users/<USER>/apps/<USER>/public/wp-includes/blocks/block.php:35) in <b>/srv/users/<USER>/apps/<USER>/public/wp-includes/rest-api/class-wp-rest-server.php</b> on line <b>1642</b><br />
<br />
<b>Warning</b>: Cannot modify header information - headers already sent by (output started at /srv/users/<USER>/apps/<USER>/public/wp-includes/blocks/block.php:35) in <b>/srv/users/<USER>/apps/<USER>/public/wp-includes/rest-api/class-wp-rest-server.php</b> on line <b>1642</b><br />
[{"id":6,"date":"2021-05-04T14:02:17","date_gmt":"2021-05-04T14:02:17","guid":{"rendered":"https:\/\/vivacious-aardvark.jurassic.ninja\/2021\/05\/04\/untitled-reusable-block\/","raw":"https:\/\/vivacious-aardvark.jurassic.ninja\/2021\/05\/04\/untitled-reusable-block\/"},"modified":"2021-05-04T14:36:16","modified_gmt":"2021-05-04T14:36:16","password":"","slug":"untitled-reusable-block","status":"publish","type":"wp_block","link":"https:\/\/vivacious-aardvark.jurassic.ninja\/2021\/05\/04\/untitled-reusable-block\/","title":{"raw":"RB 1"},"content":{"raw":"<!-- wp:heading -->\n<h2>Heading<\/h2>\n<!-- \/wp:heading -->\n\n<!-- wp:paragraph -->\n<p>Paragraph<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:block {\"ref\":6} \/-->","protected":false,"block_version":1},"template":"","_links":{"self":[{"href":"https:\/\/vivacious-aardvark.jurassic.ninja\/wp-json\/wp\/v2\/blocks\/6"}],"collection":[{"href":"https:\/\/vivacious-aardvark.jurassic.ninja\/wp-json\/wp\/v2\/blocks"}],"about":[{"href":"https:\/\/vivacious-aardvark.jurassic.ninja\/wp-json\/wp\/v2\/types\/wp_block"}],"wp:attachment":[{"href":"https:\/\/vivacious-aardvark.jurassic.ninja\/wp-json\/wp\/v2\/media?parent=6"}],"wp:action-publish":[{"href":"https:\/\/vivacious-aardvark.jurassic.ninja\/wp-json\/wp\/v2\/blocks\/6"}],"wp:action-unfiltered-html":[{"href":"https:\/\/vivacious-aardvark.jurassic.ninja\/wp-json\/wp\/v2\/blocks\/6"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}]
Some parts of the log have been replaced with <USER> just in case they were sensitive.
I Investigated this case in the web version but I couldn't reproduce it, as far as I checked, the requests on both web and mobile platforms in self-hosted sites are almost identical. However, there's one difference, on web there's an additional header (accept: application/json, */*;q=0.1) in the request. In fact, this header is explicitly added by default on the web version, besides the code includes a reference to an issue from WordPress that might explain why we need to set this header 🤔 .
Test
I ran a quick test by adding this header in the main apps and surprisingly it fixed the issue but only for self-hosted sites without Jetpack, you can check the details for each platform below.
// The backend uses the Accept header as a condition for considering an
// incoming request as a REST request.
//
// See: https://core.trac.wordpress.org/ticket/44534
additionalHeaders["Accept"] = "application/json, */*;q=0.1" as AnyObject?
// The backend uses the Accept header as a condition for considering an
// incoming request as a REST request.
//
// See: https://core.trac.wordpress.org/ticket/44534
request.addHeader("accept", "application/json, */*;q=0.1")
Unfortunately, this is still happening for self-hosted sites with Jetpack, in this case, the main apps are making the requests to the site via WP.com - Jetpack so even setting the Accept header doesn't address it. In the future, it would be nice to explore how does Jetpack makes this request.
Closing the issue as Reusable blocks are only available in WPCOM sites. If in the future, we work to enable them in self-hosted sites, we'd need to tackle this.
Describe the bug
When a self-hosted site has a reusable block that contains a self-reference, it produces a bad response on every request to the reusable blocks endpoint (
v2/blocks
path), breaking the reusable block functionality.This is reproducible on self-hosted sites with and without Jetpack, although the error response is different.
Without Jetpack
To Reproduce
/wp-json/wp/v2/blocks
and observe that the data is not JSON formatHere I copied an example of one:
Request response
Some parts of the log have been replaced with
<USER>
just in case they were sensitive.With Jetpack
To Reproduce
/wp/v2/sites/<SITE_ID>/blocks
and observe that the response code is500
Request response:
In iOS on a self-hosted site with Jetpack connected, it produces the following error that could lead to a crash:
Expected behavior
Requests to
blocks
endpoint should be successful.Smartphone (please complete the following information):
The text was updated successfully, but these errors were encountered: