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

WordPress Trac noreply at wordpress.org
Tue Nov 22 01:42:05 UTC 2016


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

Comment (by pento):

 Reading through [attachment:38342.9.diff], here are some thoughts:

 * `wp_dashboard_recent_drafts()` should be deprecated, and the docs for
 `dashboard_recent_drafts_query_args` moved to
 `rest_filter_quick_draft_query()`.
 * I'm not too worried about losing the `wp_trim_words` filter, but losing
 the `get_edit_post_link` filter will likely be be a problem.
 * There's no fallback for the post title being empty, which
 `_draft_or_post_title()` used to take care of. This is necessary for the
 edit link to work.
 * Are the `'object' === typeof attributes.content` and `'object' ===
 typeof attributes.title` checks necessary? These attributes should always
 be objects.
 * I'm not wild about the date formatting code. It feels messy to be doing
 it in the `normalizeAttributes()` method. I tend to agree that the API
 shouldn't return a formatted date, so a `wp.formatting`-based method for
 formatting a date would useful to introduce a standard practice. Using
 `Intl` with a fallback seems like a reasonable method, that could be
 upgraded at a later date. Integrating something like Moment.js, as
 @jnylen0 suggested, is a large task that could not be accomplished
 quickly.
 * I agree with @adamsilverstein that `wp_localize_script()` is fine for
 Dashboard-based features.

 Generally speaking, the JavaScript feel overly verbose, I found it tricky
 to keep track of code paths in my head, which shouldn't be happening for
 such a simple feature. Developer inaccessible JavaScript has been a major
 inhibitor of gaining new JavaScript core contributors in the past (see:
 the difficulties we have in maintaining the Media modal), I really don't
 want us to be encoding standard practices that make it harder for folks to
 get started with contributing.

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


More information about the wp-trac mailing list