[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 jnylen0):

 Replying to [comment:6 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.

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