Make WordPress Core

Opened 4 years ago

Closed 3 years ago

Last modified 3 years ago

#53957 closed defect (bug) (reported-upstream)

Create a POST API endpoint for rendering legacy widgets

Reported by: zieladam's profile zieladam Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Widgets Keywords: has-patch has-unit-tests
Focuses: rest-api Cc:

Description

Core counterpart of [issue 33540:https://github.com/WordPress/gutenberg/issues/33540] from the Gutenberg repo. We need both issues because the API change

Legacy widgets are rendered using an <iframe /> with all the attributes data URLencoded and packed into src.

This works when there aren't many parameters or when the server tolerates very long query strings. Unfortunately, when one of these conditions isn't met, we may see an error 414 URI too long.

To remedy the problem, we need to send the widget attributes outside of the query string. POST request body is a reasonable candidate and so this ticket is all about adding such an endpoint to the API.

Change History (12)

This ticket was mentioned in PR #1508 on WordPress/wordpress-develop by adamziel.


4 years ago
#1

  • Keywords has-patch has-unit-tests added

Related to https://github.com/WordPress/gutenberg/issues/33540
Trac Ticket: https://core.trac.wordpress.org/ticket/53957

This adds a /wp/v2/widget-types/<widget type>/render endpoint which accepts POST data and returns the same output as the previous iframe-oriented GET endpoint.

Test plan:

  1. Go to /wp-admin/widgets.php
  2. Paste the following script into your devtools:

{{{js
wp.apiFetch({

"path": "/index.php?rest_route=%2Fwp%2Fv2%2Fwidget-types%2Ftext%2Frender&context=edit&per_page=100&_locale=user",
"method": "POST",
"data": {"id_base":"text","instance":{"encoded":"YTo0OntzOjU6InRpdGxlIjtzOjU6InRlc3QyIjtzOjQ6InRleHQiO3M6NToidGVzdDMiO3M6NjoiZmlsdGVyIjtiOjE7czo2OiJ2aXN1YWwiO2I6MTt9","hash":"6bd53d501ad76cfbc50ef417d78dc9f1","raw":{"title":"test2","text":"test3","filter":true,"visual":true}}}

})
.then(console.log.bind(console))
.catch(console.error.bind(console));
}}}

  1. Confirm the response was successful and the widget got rendered as expected.

Alternatives considered:

  • ServerSideRender – we need to render a full HTML document with wp_head(), CSS links, maybe some additional scripts, and this is much more that I would like to return from a block rendering API.
  • Updating the existing admin_init hook handler to work with POST requests – it's tricky and doesn't seem right, I don't think we should stretch hooks like that. This clearly is an API request so let's treat it as such.

This ticket was mentioned in PR #1508 on WordPress/wordpress-develop by adamziel.


4 years ago
#2

Related to https://github.com/WordPress/gutenberg/issues/33540
Trac Ticket: https://core.trac.wordpress.org/ticket/53957

This adds a /wp/v2/widget-types/<widget type>/render endpoint which accepts POST data and returns the same output as the previous iframe-oriented GET endpoint.

Test plan:

  1. Go to /wp-admin/widgets.php
  2. Paste the following script into your devtools:

{{{js
wp.apiFetch({

"path": "/index.php?rest_route=%2Fwp%2Fv2%2Fwidget-types%2Ftext%2Frender&context=edit&per_page=100&_locale=user",
"method": "POST",
"data": {"id_base":"text","instance":{"encoded":"YTo0OntzOjU6InRpdGxlIjtzOjU6InRlc3QyIjtzOjQ6InRleHQiO3M6NToidGVzdDMiO3M6NjoiZmlsdGVyIjtiOjE7czo2OiJ2aXN1YWwiO2I6MTt9","hash":"6bd53d501ad76cfbc50ef417d78dc9f1","raw":{"title":"test2","text":"test3","filter":true,"visual":true}}}

})
.then(console.log.bind(console))
.catch(console.error.bind(console));
}}}

  1. Confirm the response was successful and the widget got rendered as expected.

Alternatives considered:

  • ServerSideRender – we need to render a full HTML document with wp_head(), CSS links, maybe some additional scripts, and this is much more that I would like to return from a block rendering API.
  • Updating the existing admin_init hook handler to work with POST requests – it's tricky and doesn't seem right, I don't think we should stretch hooks like that. This clearly is an API request so let's treat it as such.

#3 @zieladam
4 years ago

Github integration says Approved, Changes Requested, but I don't see any changes requested on that PR.

spacedmonkey commented on PR #1508:


4 years ago
#4

CC @TimothyBJacobs

#5 @swissspidy
4 years ago

  • Component changed from General to Widgets
  • Focuses rest-api added

adamziel commented on PR #1508:


4 years ago
#6

@TimothyBJacobs thank you for reviewing! I just addressed all your feedback.

TimothyBJacobs commented on PR #1508:


4 years ago
#7

Thanks @adamziel! The only small tweak is that the @since tags should come before the @param tags.

noisysocks commented on PR #1508:


3 years ago
#8

Last minute feedback, sorry!

Did you consider incorporating this functionality into the existing /widget-types/:id/encode endpoint? /encode is an existing RPC-style endpoint that already accepts instance as an argument and returns preview in the response. The only difference is that /encode does not output all of the wrapping HTML including scripts and styles and whatnot. Perhaps it could, though.

noisysocks commented on PR #1508:


3 years ago
#9

Now that I think about it, maybe we should only add it to Gutenberg repo and not here 🤔 and then backport it on the next major release

Yes we probably should do this. That way it can be used by https://github.com/WordPress/gutenberg/pull/34184, too.

adamziel commented on PR #1508:


3 years ago
#10

Let's continue in the Gutenberg repo then: https://github.com/WordPress/gutenberg/pull/34230

#11 @zieladam
3 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

I am closing this ticket in favor of a Guteneberg one: https://github.com/WordPress/gutenberg/pull/34230

#12 @peterwilsoncc
3 years ago

  • Resolution changed from invalid to reported-upstream
Note: See TracTickets for help on using tickets.