WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#40238 closed enhancement (maybelater)

WP REST API post content often relies on inaccessible enqueued JS and CSS

Reported by: mnelson4 Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.8
Component: REST API Keywords:
Focuses: Cc:

Description

Often post content has shortcodes in it which rely on JS and CSS in order to be displayed properly. But when retrieving posts over the WP REST API, there is no way to get that JS or CSS.

For example, let's say I create a custom shortcode that shows a countdown timer. In order to do that, when rendering the shortcode, my code enqueues JS to be outputted in the footer, and returns some HTML placeholder. When the JS runs in the footer, it converts that HTML placeholder into my sick countdown timer.

When I retrieve the post via the WP REST API, I only get the rendered post content, which contains the HTML placeholder, but that's not very useful without the JS, and there's no way to get that JS file over the WP REST API, right?

So should the WP REST API somehow expose what JS and CSS is required to display post content correctly? Or what is to be done with shortcodes which rely on JS or CSS to be displayed correctly?

Change History (7)

#1 in reply to: ↑ description @jteague
5 years ago

  • Keywords dev-feedback added
  • Resolution set to invalid
  • Status changed from new to closed

Replying to mnelson4:

So should the WP REST API somehow expose what JS and CSS is required to display post content correctly? Or what is to be done with shortcodes which rely on JS or CSS to be displayed correctly?

Thank you for your submission. I understand the issue you are having. However, there is currently no native support for filtering shortcodes returned in JSON. Please refer your question to the WordPress support forum for advice.

#2 @jnylen0
5 years ago

  • Resolution changed from invalid to maybelater
  • Type changed from defect (bug) to enhancement

IMO this is neither invalid nor a support issue. Rather, this is a feature of the design of shortcodes (or a deficiency, depending on how you look at it). I hope we can do a better job of addressing this in the block-based editor project by ensuring that blocks are "serialized" to semantically meaningful HTML during rendering.

In the meantime I would suggest providing enough information in your rendered shortcodes to reconstruct the intended functionality, perhaps along with a register_rest_field or two for extra information.

#3 @ocean90
5 years ago

  • Keywords dev-feedback removed
  • Milestone Awaiting Review deleted

This ticket was mentioned in Slack in #core-editor by jnylen. View the logs.


5 years ago

This ticket was mentioned in Slack in #core by johnteague. View the logs.


5 years ago

#6 follow-up: @mnelson4
5 years ago

Thanks for the feedback @jteague and @jnylen0. Ya, this certainly isn't a bug report or a specific feature request yet, more pointing out an issue that doesn't seem to have any good solution with WP API core, yet. And also wanting to explore ideas for any ideal solutions. I admit this situation may get pretty hairy, and it might be best to first have a feature plugin attempt any generalized fix, rather than introduce it into WP core right away, if at all.

I hope we can do a better job of addressing this in the block-based editor project by ensuring that blocks are "serialized" to semantically meaningful HTML during rendering.

Are you suggesting that each block would contain its JS and CSS inline, rather than in the header or footer? If so, I agree that might be promising once developers switch to that method,

In the meantime I would suggest providing enough information in your rendered shortcodes to reconstruct the intended functionality, perhaps along with a register_rest_field or two for extra information.

So @jnylen0 are you suggesting a developer could put a reference to the javascript and CSS files in an extra field on the post's JSON entity (e.g., name it "required_js")? This way API clients could look in that extra field, find what JS and CSS files are necessary to display the post's content. Is that about right?

If we wanted a generalized solution that accommodates the current approach to enqueuing JS and CSS, it could look something like this: JSON entities for posts and pages could always contain read-only fields named "html_head_contents" and "html_footer_contents" which would basically contain the full contents of the header and footer (containing all the CSS files, JS files, and inline JS and CSS too) that would be displayed on a normal request for that page or post. Then API clients can render those if they want.

Or, instead of having two fields containing only HTML, maybe they could be JSON objects which have the same info, but in a more machine-readable format. Eg an array of URLs to javascript files, CSS files, and each script or style tag could be it's own entry in the array.

Thoughts? I admit it might not be feasible to have a generalized solution to this problem, even by a plugin. Instead, maybe the problem should just be avoided by post content always including its JS and CSS dependencies inside its content (which is currently NOT the recommended approach).

Last edited 5 years ago by mnelson4 (previous) (diff)

#7 in reply to: ↑ 6 @jnylen0
5 years ago

Replying to mnelson4:

Are you suggesting that each block would contain its JS and CSS inline, rather than in the header or footer? If so, I agree that might be promising once developers switch to that method,

Not really - this sounds like it would get extremely messy in practice. Instead I'd rather see an increased focus on markup that is semantically meaningful "on its own". I know this doesn't really solve the issue at hand, but it makes it easier perhaps.

So @jnylen0 are you suggesting a developer could put a reference to the javascript and CSS files in an extra field on the post's JSON entity (e.g., name it "required_js")? This way API clients could look in that extra field, find what JS and CSS files are necessary to display the post's content. Is that about right?

Something like that, though the field should be prefixed with the name of the plugin. If you'd rather try to create a generalized solution, then I think there should be a plugin that adds the fields you mentioned like html_head_contents, and this plugin should allow other plugins to register with it once they've verified that their JS/CSS will work reasonably well in a context that is not the full WP site. (Which also sounds quite difficult to achieve.)

Thoughts? I admit it might not be feasible to have a generalized solution to this problem, even by a plugin. Instead, maybe the problem should just be avoided by post content always including its JS and CSS dependencies inside its content (which is currently NOT the recommended approach).

I agree that it seems almost impossible to come up with a "full" generalized solution here. For example, many plugins are going to assume that their JS is going to run in the context of a post rendered on a WP site, depend on WP-bundled libraries, etc. Including the existing JS directly in an API response is therefore not very valuable.

Note: See TracTickets for help on using tickets.