[wp-trac] [WordPress Trac] #40238: WP REST API post content often relies on inaccessible enqueued JS and CSS

[WordPress Trac]

#40238: WP REST API post content often relies on inaccessible enqueued JS and CSS
-------------------------+-------------------------
 Reporter:  mnelson4     |       Owner:
     Type:  enhancement  |      Status:  closed
 Priority:  normal       |   Milestone:
Component:  REST API     |     Version:  trunk
 Severity:  normal       |  Resolution:  maybelater
 Keywords:               |     Focuses:
-------------------------+-------------------------

Comment (by mnelson4):

 Thanks for the feedback @jteague and @jnylen0. Ya, this certainly isn't a
 bug report or a specific feature request yet, more looking 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).

--
Ticket URL: <https://core.trac.wordpress.org/ticket/40238#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform