[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:  new        
 Priority:  normal        |   Milestone:  Unassigned 
Component:  XML-RPC       |     Version:  2.9.2      
 Severity:  normal        |    Keywords:             
--------------------------+-------------------------------------------------
 When a post is submitted either through the web editor interface or from
 an API call to newPost or editPost, the content of the post is inevitably
 passed through the content_save_pre filter.

 And when a post is opened for editing in the web editor, the content is
 passed through filters such as the_editor_content and  content_edit_pre.

 However, when a post is fetched for editing via XMLRPC API calls such as
 getPost or getRecentPosts, the content_edit_pre filter is never reached.

 This leads to a situation where whatever massaging of the content that a
 plugin may peform on the way into the database is not reversed on the way
 back out, for clients of the API. A concrete example of this problem is
 with the popular Syntax Highlighter Evolved:

 http://www.viper007bond.com/wordpress-plugins/syntaxhighlighter/

 This plugin performs encoding of the post content before it is stored in
 the database, and it counts on being able to decode that content by adding
 filters to hooks such as the_editor_content. However, none of these
 filters are reached via the API, leading to "corrupted content" when users
 try to edit posts from API clients such as the iPhone WordPress app, or my
 desktop editor, MarsEdit.

 (My previous bug report #10802 exhibits the same symptoms of this bug, but
 this is a different cause).

 In summary:

 1. WordPress needs to establish a clear, baseline hooks for massaging
 content before it is saved to the database, and for un-massaging the
 content on the way out of the database. Currently there seems to be
 uncertainty about which hooks need to be overridden and under what
 circumstances. It seems to me that content_save_pre and content_edit_pre
 are probably good candidates for this.

 2. Whatever hooks are established as the guarantees need to be applied
 once and only once in both the web-based editing scenario, and in the API
 editing scenario.

 I think that having a well documented pair of hooks for this purpose that
 works identically in the web editing and API editing cases will do a lot
 to ensure correct behavior when plugins are installed that massage
 content, and will make it easy for plugin developers to "do the right
 thing" without relying on hooks that are specific only to the web editor,
 or to the API.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/12939>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software