[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