[wp-trac] [WordPress Trac] #18429: Create custom post types via XMLRPC

[WordPress Trac]

#18429: Create custom post types via XMLRPC
----------------------------+------------------------
 Reporter:  nprasath002     |       Owner:  westi
     Type:  task (blessed)  |      Status:  reviewing
 Priority:  normal          |   Milestone:  3.4
Component:  XML-RPC         |     Version:
 Severity:  normal          |  Resolution:
 Keywords:  has-patch       |
----------------------------+------------------------
Changes (by maxcutler):

 * cc: max@… (added)


Comment:

 I know `mw_newPost` uses `get_default_post_to_edit` to get an auto-draft
 to work on before calling `wp_insert_post`, but I'm wondering if that's
 something we really want to copy. Auto-drafts get cleaned out after seven
 days, but that can leave a significant amount of cruft behind if
 `wp_insert_post` fails.

 I think I'd prefer if we validated everything before calling
 `wp_insert_post`, and then only performed the saving for sticky, taxonomy
 terms, post format, custom fields, and enclosures after the call, when the
 post truly exists.

 Other minor things:

 * The 'xmlrpc_call' `do_action` should be moved up so that it's
 immediately after the login check (to be consistent with all of the other
 methods).
 * There are duplicate `absint( $post_data['post_author'] )` calls which
 should be removed in favor of a single instance before the `if (
 isset(...))`. Because even in the `else` branch, we want that field to be
 cast to an int.
 * Should we return an error if `tax_input` is not an array? Right now that
 `if` has no `else`.
 * There's an undefined variable `$terms_needed` used in the term handling
 code.
 * Can you separate the complex `if` statements for `comment_status` and
 `ping_status`? Right now it's hard to read, it'd probably be better with
 an `if ( isset(...))` and a nested `if` testing the value. Speaking of
 which, should we return an error for invalid statuses, or is silently
 ignoring it okay? I know mw_newPost ignores it, but that doesn't mean
 wp_newPost has to.
 * The existing wp_* methods use `blog_id` instead of `blog_ID`. It doesn't
 really matter since it's not used, but consistency is a good thing.
 * I noticed some WP coding style violations, especially with lack of
 spaces around `!`.

 One final thought: it might be nice to have a filter on `$post_data` right
 before the call to `wp_insert_post`, with `content_struct` as an argument.
 Might also want to consider something like in #17109.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/18429#comment:22>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software