[wp-trac] [WordPress Trac] #12939: Counterpart to content_save_pre hook not called when getting post content via API

[WordPress Trac]

#12939: Counterpart to content_save_pre hook not called when getting post content
via API
--------------------------+------------------------------
 Reporter:  redsweater    |       Owner:  josephscott
     Type:  defect (bug)  |      Status:  reopened
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  XML-RPC       |     Version:  2.9.2
 Severity:  normal        |  Resolution:
 Keywords:  dev-feedback  |     Focuses:
--------------------------+------------------------------

Comment (by redsweater):

 I can confirm the bug still exists. I just tested with WP trunk from SVN
 and against the latest version of Syntax Highlighter Evolved.

 This is still an issue that my customers run into, and I have to imagine
 any users of WordPress's iOS app are vulnerable to it. The behavior is
 subtle but the problems could span a very wide range of severities from
 mild to extreme, depending on the expectations and assumptions of what
 filtering will be done in the "edit_pre" filters.

 To elaborate on @DrewAPicture's comments in the last update about whether
 it has even been confirmed that the filters are not called, I can confirm
 that they are not and I have done a little bit of investigation explaining
 why not. Note that this is not my area of expertise but it would be
 valuable to finally see this fixed, so if there's anything I can do to
 help nudge the bug along I'd like to help.

 The core of the problem seems to be that in fact when any posts are
 fetched for the service of an API call such as wp.getPosts, the lower-
 level wp_get_recent_posts in post.php, and ultimately the get_post()
 function call, is reached in such a way that the "context" parameter will
 always be raw, and thus none of the usual filtering is applied.

 By contrast, the get_post() call is reached when editing a post through
 the web UI, through the explicit call in wp-admin/post.php's "edit:" state
 case to:

 {{{
 $post = get_post($post_id, OBJECT, 'edit');
 }}}

 So an important question that I think needs to be answered is: should
 fetches of posts via the API default to massaging the content for 'edit'
 context? I can see an argument against this, as it all depends on what the
 purpose of using the API is. However, given that a good number of API
 clients are in fact using the API to provide a similar editing console to
 what you find in wp-admin/post.php, I think the API should either default
 to providing post content with 'edit' context filters applied, or else
 provide a means for API clients to specify which context mode they are
 seeking the post content for. For example an API client that uses the data
 strictly for display may in fact want to specify that the 'display'
 context is used in fetching the desired posts.

 In summary: currently the post content retrieved via the API is 'raw' and
 not filtered for any context, but this makes it impossible to participate
 via the API e.g. as a suitable alternative for reliably editing post
 content.

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