Make WordPress Core

Opened 22 months ago

Closed 22 months ago

Last modified 16 months ago

#21016 closed defect (bug) (invalid)

Quick Edit removes custom added edit columns on save

Reported by: sillybean Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.3
Component: Quick/Bulk Edit Keywords:
Focuses: Cc:


In 3.4, quick editing an entry makes any custom columns added with the manage_pages_columns and manage_pages_custom_column filters disappear on save. That is, ajax returns only the built-in columns.

I've attached a screenshot from a site where I've added ID, Content Owner, Content Status, and Expiration columns. (This is from my Content Audit plugin.) The top row has just been quick edited, and shows only title, author, and date. (Comments had been turned off in screen options.)

Attachments (1)

Screen Shot 2012-06-18 at 4.17.42 PM.png (25.6 KB) - added by sillybean 22 months ago.

Download all attachments as: .zip

Change History (7)

comment:1 follow-up: webord22 months ago

It's happening to me to.

I have installed the Yoast SEO Plugin.

It's not return the columns from the plugins.

After doing some digging I found that It might have to do with some problem on the Screen ID, because the columns depends on the page you are.

Couldn't find where the bug comes from, but it's a start.

Last edited 22 months ago by webord (previous) (diff)

comment:2 nacin22 months ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed
  • Version changed from 3.4 to 3.3

I can reproduce this in 3.3 for your plugin as well.

The issue is that content_audit_columns() uses $_GET['post_type'] to determine which post type is being requested. This is not set during an inline save. $_REQUEST['post_type'] would work here. There may be something better to check; I didn't look.

You might have found it to work in 3.3 based on your settings, but it does not work with the plugin's defaults. By default, only pages are audited. But if $_GET['post_type'] is not set, it will fall back to posts, which is by default off. Turning on auditing for posts on the settings screen does allow the quick edit to work in 3.4, as it would then use the post options.

A side note, on activation, I get a lot of warnings in my log, because there are no options in the DB but there is some code that expects them to be present. Things like in_array() failing as it doesn't get an array.

comment:3 in reply to: ↑ 1 nacin22 months ago

Replying to webord:

Hi webord, please open a support thread at http://wordpress.org/extend/plugins/wordpress-seo/. If it is indeed a bug in core, I imagine we will hear from joostdevalk pretty quickly. Or, if you have reason to think it is core, you can open a ticket separate from this one.

comment:4 SergeyBiryukov22 months ago

Sounds like a duplicate of #18496.

comment:5 nacin22 months ago

		if ( 'page' == $post_type )
			$posts_columns = apply_filters( 'manage_pages_columns', $posts_columns );
			$posts_columns = apply_filters( 'manage_posts_columns', $posts_columns, $post_type );
		$posts_columns = apply_filters( "manage_{$post_type}_posts_columns", $posts_columns );

manage_posts_columns passes $post_type. manage_{$post_type}_posts_columns should as well, but that could at least be gleaned from current_filter(). If anyone wants to open a new ticket advocating for the new argument, that seems fine for 3.5.

comment:6 brasofilo16 months ago

For the records, I had the same issue and it was happening because of the check

'edit.php' == $pagenow 

QuickEdit $pagenow is admin-ajax.php, so the necessary actions don't fire up after the post is updated and the custom columns are not rendered back.

This ticket, #18496 and this WPSE thread were the only places I found this issue being raised.

Note: See TracTickets for help on using tickets.