Make WordPress Core

Opened 13 years ago

Last modified 5 years ago

#16392 new enhancement

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

Reported by: denis-de-bernardy's profile Denis-de-Bernardy Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.1
Component: Quick/Bulk Edit Keywords: needs-patch
Focuses: Cc:


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:

Plugin SVN:

Attachments (4)

WP 3.0.png (132.8 KB) - added by Denis-de-Bernardy 13 years ago.
WP 3.1.png (122.5 KB) - added by Denis-de-Bernardy 13 years ago.
template.php.patch (344 bytes) - added by outis 12 years ago.
Add 'get_inline_data' action to function get_inline_data so plugins can add custom field data. (533 bytes) - added by outis 12 years ago.
Update inlineEditPost.edit to automatically set custom input fields.

Download all attachments as: .zip

Change History (23)

#1 @nacin
13 years ago

  • Milestone changed from Awaiting Review to 3.1

#2 @garyc40
13 years ago

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.

#3 @JustinSainton
13 years ago

Testing with dev branch.

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.

#6 follow-up: @johnjamesjacoby
13 years ago

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

#7 @nacin
13 years ago

  • Keywords reporter-feedback needs-investigating added; blocker removed
  • Severity changed from critical to normal

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.

#8 in reply to: ↑ 6 @Denis-de-Bernardy
13 years ago

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.

#9 @Denis-de-Bernardy
13 years ago

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?

#10 @nacin
13 years ago

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

#11 @Denis-de-Bernardy
13 years ago

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.

#12 @Denis-de-Bernardy
13 years ago

  • Component changed from General to Quick/Bulk Edit
  • Keywords needs-patch added; reporter-feedback needs-investigating removed
  • Milestone changed from 3.1 to Future Release
  • Summary changed from Quick Edit breaks and loses meta values from 3.0 to 3.1 with custom post types to Quick Edit API should allow to pick up custom field values automatically
  • Type changed from defect (bug) to enhancement

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.

#13 @Denis-de-Bernardy
13 years ago

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

#14 @sillybean
13 years ago

  • Cc steph@… added

12 years ago

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

12 years ago

Update inlineEditPost.edit to automatically set custom input fields.

#15 @outis
12 years ago

Denis' points are addressed by template.php.patch and, 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') {
    <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 } ?>
add_action('quick_edit_custom_box', 'display_custom_quick');

#16 @SergeyBiryukov
12 years ago

  • Keywords has-patch added; needs-patch removed

#17 @stephenh1988
12 years ago

  • Cc stephen@… added

#18 @chriscct7
10 years ago

  • Keywords needs-refresh added; has-patch removed

#19 @chriscct7
8 years ago

  • Keywords needs-patch added; needs-refresh removed
Note: See TracTickets for help on using tickets.