[wp-trac] [WordPress Trac] #23471: Abstraction of post format parameters (wp_update_post(), XML-RPC, template tags) (was: Abstraction of post format parameters (wp_insert_post(), XML-RPC, template tags))

WordPress Trac noreply at wordpress.org
Wed Feb 13 19:57:56 UTC 2013


#23471: Abstraction of post format parameters (wp_update_post(), XML-RPC, template
tags)
-------------------------+------------------------------
 Reporter:  johnbillion  |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  General      |     Version:  trunk
 Severity:  normal       |  Resolution:
 Keywords:               |
-------------------------+------------------------------
Description changed by johnbillion:

Old description:

> #19570 is introducing a UI for post formats. Correspondingly, various
> post meta fields will be introduced to store the extended data that's
> used in some post formats (eg. the URL field for a link or the source
> field for a quote).
>
> Anything that interacts with the XML-RPC API and wants to support post
> formats (eg. future versions of the [http://wordpress.org/extend/mobile/
> WordPress mobile apps]) will therefore need to:
>
>  1. Send the various post format meta fields in its requests, and
>  2. Receive the various post format meta fields in responses.
>
> There should be some abstraction available at all levels of saving and
> fetching posts, don't we have to deal with the post meta fields directly.
> We should:
>
>  1. Introduce a new parameter to the `wp.newPost` and `wp.editPost` XML-
> RPC methods for specifying the values of the extended post format fields
> when saving posts,
>  2. Introduce a new parameter to the `wp.getPost` and `wp.getPosts` XML-
> RPC methods for returning the values of the extended post format fields
> when fetching posts,
>  3. Introduce a new parameter to `wp_insert_post()` for specifying the
> values of the extended post format fields when saving posts, and
>  4. Introduce template tags for displaying/returning the values of the
> extended post format fields.
>
> Point number 4 may be being covered somewhere else. I know it's been
> mentioned in IRC but I couldn't find mention of it on Trac.
>
> The end result of this is that extended post format data is abstracted
> from its storage method.
>
> Consideration: Which of these fields will be required and which are
> optional (on a per-post-format basis).
>
> Thoughts? I'm happy to volunteer a first patch (or patches).

New description:

 #19570 is introducing a UI for post formats. Correspondingly, various post
 meta fields will be introduced to store the extended data that's used in
 some post formats (eg. the URL field for a link or the source field for a
 quote).

 Anything that interacts with the XML-RPC API and wants to support post
 formats (eg. future versions of the [http://wordpress.org/extend/mobile/
 WordPress mobile apps]) will therefore need to:

  1. Send the various post format meta fields in its requests, and
  2. Receive the various post format meta fields in responses.

 There should be some abstraction available at all levels of saving and
 fetching posts, don't we have to deal with the post meta fields directly.
 We should:

  1. Introduce a new parameter to the `wp.newPost` and `wp.editPost` XML-
 RPC methods for specifying the values of the extended post format fields
 when saving posts,
  2. Introduce a new parameter to the `wp.getPost` and `wp.getPosts` XML-
 RPC methods for returning the values of the extended post format fields
 when fetching posts,
  3. Introduce a new parameter to `wp_update_post()` for specifying the
 values of the extended post format fields when saving posts, and
  4. Introduce template tags for displaying/returning the values of the
 extended post format fields.

 Point number 4 may be being covered somewhere else. I know it's been
 mentioned in IRC but I couldn't find mention of it on Trac.

 The end result of this is that extended post format data is abstracted
 from its storage method.

 Consideration: Which of these fields will be required and which are
 optional (on a per-post-format basis).

 Thoughts? I'm happy to volunteer a first patch (or patches).

--

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


More information about the wp-trac mailing list