Quick Edit API should allow to pick up custom field values automatically

[Denis-de-Bernardy]

Attached are two screenshots of the same plugin in 3.0 and 3.1. The plugin code is unchanged between the two. Only WP gets an svn switch.

I'm investigating where it's coming from, but as you can note from the screenshots 3.0 lists nada for that plugin on the one hand side, while 3.1 lists actual fields and leaves them blank. The latter causes data loss when Quick-Editing a row.

Cross-referencing ticket references:

​http://code.google.com/p/wp-e-commerce/issues/detail?id=327

Plugin SVN:

​http://svn.wp-plugins.org/wp-e-commerce/branches/3.8-development

[garyc40]

What version of wp-e-commerce are you testing with?

The one that can be downloaded from WP plugin directory does not have that UI (separate Products section), while 3.8 beta seems to be working fine with Quick Edit.

[JustinSainton]

Testing with dev branch.

​http://svn.wp-plugins.org/wp-e-commerce/branches/3.8-development/

Refactored everthing to use show_ui in the backend, so the quick edit is being handled via WP. To get it working in both 3.0 and 3.1, we just had to add

add_filter( 'manage_wpsc-product_posts_columns', 'wpsc_additional_column_names' );

Without that hook, it worked fine in 3.1, but not at all in 3.0.

[johnjamesjacoby]

Code in 3.1 :

​http://core.trac.wordpress.org/browser/trunk/wp-admin/includes/class-wp-posts-list-table.php#L984

---

Code in 3.0 branch

​http://core.trac.wordpress.org/browser/branches/3.0/wp-admin/includes/template.php#L1142

$columns is loaded :

​http://core.trac.wordpress.org/browser/branches/3.0/wp-admin/includes/template.php#L875

---

Seems like it might be a difference between 'wp_manage_posts_columns' and $this->get_column_info() but I'm still looking into that.

[johnjamesjacoby]

Possibly related:

​http://core.trac.wordpress.org/ticket/12398

[johnjamesjacoby]

Just noticed Justin's comment, which sounds like it's a fix for WPEC? Is this a non-issue then?

[nacin]

Per a Twitter conversation with some of the WPeC guys (and Justin's comment above), this seems to be handled. But I'm curious what the core change was here, and how it could be reproduced, and whether it is a problem.

In the meantime, I am downgrading the severity of this bug. Tempted to move to Awaiting Review but I want to be diligent.

[Denis-de-Bernardy]

Replying to johnjamesjacoby:

Just noticed Justin's comment, which sounds like it's a fix for WPEC? Is this a non-issue then?

It's still broken (in both versions, since Justin's changeset) as far as I can tell. As things stand it might be related to the plugin -- the ajax that fills in the fields appears to be kaput, or something like that. Investigating further and reporting back when I nail it down.

[Denis-de-Bernardy]

On a separate note, I'm noting a duplicate filter name, in wp-posts-list-table.php and wp-terms-list-table.php respectively:

do_action( $bulk ? 'bulk_edit_custom_box' : 'quick_edit_custom_box', $column_name, $screen->post_type );

do_action( 'quick_edit_custom_box', $column_name, 'edit-tags', $tax->name );

Do we really want to be using the same filter name here?

[nacin]

We don't, but that's not a change from 3.0. #15285

[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.

[Denis-de-Bernardy]

To rephrase the above, imo:

1. We're missing a hook in get_inline_data() that would allow plugins to register custom field values.
2. inlineEditPost.edit() should be edited so it fills custom UI fields automatically.

[Denis-de-Bernardy]

Fix for this particular plugin, in case other plugin authors run into it:

​http://code.google.com/p/wp-e-commerce/issues/detail?id=327#c3

[outis]

Add 'get_inline_data' action to function get_inline_data so plugins can add custom field data.

[outis]

Update inlineEditPost.edit to automatically set custom input fields.

[outis]

Denis' points are addressed by template.php.patch and inline-edit-post.dev.js.patch, now attached to this ticket. To automatically update custom inputs, the data elements added in the 'get_inline_data' hook must have a "for" attribute set to the "name" of the input. For example:

function add_inline_data($post) {
    foreach (array('foo', 'bar', 'baz') as $field) {
        $value = esc_html(get_post_meta($post->ID, $field, TRUE));
        echo "<div for='$field'>$value</div>";
    }
}
add_action('get_inline_data', 'add_inline_data');

/* ensures quick_edit_custom_box is triggered */
function add_quickedit_column($cols) {
    $cols['quickedit'] = __('Quickedit Data');
    return $cols;
}
add_filter('manage_posts_columns', 'add_quickedit_column');


function display_custom_quick($column_name, $type) {
    if ($column_name !== 'quickedit') {
        return;
    }
    ?>
    <fieldset class="inline-edit-col-right">
      <div class="inline-edit-col inline-edit-<?php echo $column_name ?>">
        <?php foreach (array('foo', 'bar', 'baz') as $field) { ?>
          <label for="<?php echo $field ?>"><?php echo ucfirst($field) ?></label>
          <input name="<?php echo $field ?>" />
        <?php } ?>
      </div>
    </fieldset>
    <?php
}
add_action('quick_edit_custom_box', 'display_custom_quick');