id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc
12939,Counterpart to content_save_pre hook not called when getting post content via API,redsweater,josephscott,"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.
",defect (bug),reviewing,normal,Future Release,XML-RPC,2.9.2,normal,,dev-feedback,mikeschinkel@…