[wp-trac] [WordPress Trac] #38342: Quick Draft: Leverage REST API endpoints

WordPress Trac noreply at wordpress.org
Sun Nov 20 05:07:49 UTC 2016


#38342: Quick Draft: Leverage REST API endpoints
---------------------------------+-----------------------------------
 Reporter:  adamsilverstein      |       Owner:
     Type:  enhancement          |      Status:  new
 Priority:  normal               |   Milestone:  Future Release
Component:  Administration       |     Version:
 Severity:  normal               |  Resolution:
 Keywords:  has-patch 4.8-early  |     Focuses:  javascript, rest-api
---------------------------------+-----------------------------------

Comment (by aduth):

 When switching to the REST API, there's no doubt a new class of problems
 to solve crop up, that are not present in our server-side rendering world.
 I can definitely understand the want to pull render logic back to the
 server, but I think we can do better, on the front end.

 Is this any different with the the `rest_filter_quick_draft_query` filter,
 though? And the filter alone does not account for modifications that would
 have occurred previously by the
 [https://github.com/WordPress/WordPress/blob/3c7e23297ea61fb2c36b5f7f56145d06671cbf5a
 /wp-includes/formatting.php#L3372 wp_trim_words] and
 [https://github.com/WordPress/WordPress/blob/3c7e23297ea61fb2c36b5f7f56145d06671cbf5a
 /wp-includes/link-template.php#L1304 get_edit_post_link] filters in the
 [https://github.com/WordPress/WordPress/blob/3c7e23297ea61fb2c36b5f7f56145d06671cbf5a
 /wp-admin/includes/dashboard.php#L571-L580 original template logic], so
 we're in this weird place where we preserve backwards compatibility for
 some but not all of the original implementation.

 That said, I agree with your general premise that it would be best to
 leverage transformations of API data in the client, which is why I'd
 included implementations of `wp.formatting.trimWords` and
 `Intl.DateTimeFormat` in earlier patches. As we've seen here though,
 keeping 100% backwards compatibility with filters that would have
 previously run server-side will be difficult to achieve moving forward. I
 don't really have a solution to offer at the moment, and in retrospect
 would relent that my latest patch is probably a step in the wrong
 direction.

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


More information about the wp-trac mailing list