[wp-trac] [WordPress Trac] #16392: Quick Edit breaks and loses meta values from 3.0 to 3.1 with custom post types

[WordPress Trac]

#16392: Quick Edit breaks and loses meta values from 3.0 to 3.1 with custom post
types
---------------------------------------------------+------------------
 Reporter:  Denis-de-Bernardy                      |       Owner:
     Type:  defect (bug)                           |      Status:  new
 Priority:  normal                                 |   Milestone:  3.1
Component:  General                                |     Version:  3.1
 Severity:  normal                                 |  Resolution:
 Keywords:  reporter-feedback needs-investigating  |
---------------------------------------------------+------------------

Comment (by Denis-de-Bernardy):

 Ok.. I'm nailing this down to an API issue.

 As things stand when using the API, the inline editing doesn't work at all
 with the development version of the plugin (I haven't tested the beta or
 prior versions of it) with either of 3.0 or 3.1/trunk.

 In the WP admin-related js, there is some code, inlineEditPost.edit(),
 which grabs and sets WP-related data automatically for quick/bulk editing.
 The needed values get passed in template.php by get_inline_data($post),
 like so:

 {{{
 <div class="hidden" id="inline_' . $post->ID . '">
         <div class="post_title">' . $title . '</div>
         <div class="post_name">' . apply_filters('editable_slug',
 $post->post_name) . '</div>
         <div class="post_author">' . $post->post_author . '</div>
         <div class="comment_status">' . $post->comment_status . '</div>
         <div class="ping_status">' . $post->ping_status . '</div>
         <div class="_status">' . $post->post_status . '</div>
 ...
 }}}

 ... and that function has no hook for plugins to add anything extra.

 The plugin tries to work around this by inserting extra data. In addition
 to the UI that gets inserted in the above-mentioned code, it hooks onto
 manage_pages_custom_column, like so:

 {{{
 // code to extract the data
 echo '<div id="inline_' . $post->ID . '_price" class="hidden">' . $price .
 '</div>';
 }}}

 Note the different handler in the above: on the one handside, we've
 "#inline_{ID} .field", and on the other we've "#inline_{ID}_field".

 I'm saying this is an API issue because inlineEditPost.edit() should
 ideally pick these fields up as part of the same div#inline_{ID} tag, and
 fill them in automatically. Instead, it ignores the added fields and the
 plugin is, as I write, missing a method such as:

 {{{
         // Inline editing
         jQuery('a.editinline').live('click', function() {

         });
 }}}

 ... that would be responsible for filling in the extra fields on
 quick/bulk edits.

 In the immediate, I'll be adding the missing JS to the plugin, and this
 ticket can presumably be pushed into the 3.2 milestone.

 I'd like to stress the genuine API issue however. It makes things harder
 than they should be, and WP-e-commerce isn't the only plugin that will
 attempt to do this kind of stuff.

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