$_POST and $_GET are always associative keyed to field names, not sure about $post_data, probably similar to WP_Post object. You need to strip slashes from any text values in $_POST and $_GET arrays. Not so sure about WP created arrays.
Thanks for pointing out the quick edit method, it must have changed along the way some time back. I’ll fix the Codex entry.
‘content’ is the form field name and thus the key for $_POST. ‘post_content’ is the posts table column name, so is the key in the array passed as the second array to the ‘save_post’ action. In other words, ‘content’ comes from client browsers, ‘post_content’ is for data going to the posts table.
Thanks for the info. I’ve now had a look at the core files to see how $post_data is structured.
In wp-includes/class-wp-xmlrpc-server.php we find:
$content .= wp_unslash($post_data['post_content']);
and
if ( isset( $post_data['content'] ) )
$post_data['post_content'] = $post_data['content'];
When I examined $_POST and $_REQUEST (when saving a post in the normal way), $_POST contains keys (and values) for ‘post_content’ and ‘content’. $_REQUEST had a key for ‘content’, but not for ‘post_content’.
So it seems the safest way to get the post content from a function hooked into the ‘save_post’ action is probably:
$post_content = wp_unslash(!empty($_REQUEST['content']) ? $_REQUEST['content'] : $post_data['content']);
Just to correct my previous post, it seems that you can’t actually use $_REQUEST. I just tried doing a quick edit and ‘content’ (and ‘post_content’) were set on $_POST, but not on $_REQUEST. So you need to check $_POST, $_GET, and $post_data. You can’t just check $_REQUEST and $post_data as I suggested previously.
This also indicates that maybe the Codex was correct about quick edit using GET. I didn’t examine the HTTP headers, I had just assumed it was using POST since all the POST fields were filled out. But they may have been filled out by the wordpress backend rather than being filled out as part of the request.
It’s definitely POST, an AJAX POST, but a POST none the less. As determined by Firefox Http-fox plugin. Good thing, as the Codex now says quick posts use $_POST, thanks to our exchange 🙂
It’s strange $_REQUEST doesn’t work, I was under the impression it was always populated. I don’t like using it anyway, so it doesn’t bother me. It has a small security issue related to cookie values overwriting other values when the keys are the same, providing a potential injection path by manipulating site cookies.
Thanks for coming back and clarifying.
