Counterpart to content_save_pre hook not called when getting post content via API

[redsweater]

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.

For testing purposes, you can use the syntax highlighter plugin and provide this literal HTML content from the web editor or from the API:

Testing "<

[sourcecode]Testing "<[/sourcecode]

When the Syntax Highlighter plugin saves the post, it encodes the content inside [sourcecode] short tag. When you read the post back into the wordpress HTML editor, it is preserved exactly, because the plugin has the opportunity to decode the content back to original forma.t

If you load the text via the API e.g. wtih getRecentPosts or with getPost, you end up with content:

Testing "<

[sourcecode]Testing "<[/sourcecode]

The encoding that was done by the plugin has not been reversed. Note well that this is NOT simply XML encoding that you would expect from the API. The literal content as it is transferred over the wire is further encoded and then decoded by the client.

I have confirmed that the same problem affects WordPress's AtomPub API implementation.

The problem is that when done using the API, the filter that gets called is post_content_save_pre and not content_save_pre, and we have no default hooks on that filter. Is there a reason we don't have the same filters on content_save_pre as post_content_save_pre.