Make WordPress Core

Opened 12 years ago

Closed 10 years ago

Last modified 10 years ago

#21016 closed defect (bug) (invalid)

Quick Edit removes custom added edit columns on save

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

Description

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 12 years ago.

Download all attachments as: .zip

Change History (10)

#1 follow-up: @webord
12 years 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 12 years ago by webord (previous) (diff)

#2 @nacin
12 years 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.

#3 in reply to: ↑ 1 @nacin
12 years 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.

#4 @SergeyBiryukov
12 years ago

Sounds like a duplicate of #18496.

#5 @nacin
12 years ago

		if ( 'page' == $post_type )
			$posts_columns = apply_filters( 'manage_pages_columns', $posts_columns );
		else
			$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.

#6 @brasofilo
12 years 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.

#7 @codecandid
10 years ago

  • Component changed from Quick/Bulk Edit to Administration
  • Focuses administration added
  • Keywords needs-patch added
  • Resolution invalid deleted
  • Severity changed from normal to major
  • Status changed from closed to reopened
  • Summary changed from Quick Edit removes custom added edit columns on save to Breaks Tables if thead, #cb, .column-title, etc. is hidden when ajax is ran on screen using WP_List_Table

If at any point a table header column gets hidden and their is an ajax update, it completly breaks the tables...

If .column-title, thead, #cb, or anything similar ever get their visibility hidden by css, js, etc. and manage-edit{$post_type}columnshidden gets updated, it will completly break the table for that user.

This can easily be recreated:
1) open up firebug/chrome dev tools/etc. on http://www.example.com/wp-admin/edit.php
2) add

thead {display: none;}

3) Go to Screen Options on the page you have opened
4) Uncheck any column ( just to ensure that manage-editpostcolumnshidden has been added to the database )
5) Hit apply

Voila! Table Broken...

http://i.stack.imgur.com/wrYin.png

http://i.stack.imgur.com/Zvnxy.png

Last edited 10 years ago by codecandid (previous) (diff)

#8 follow-up: @SergeyBiryukov
10 years ago

  • Component changed from Administration to Quick/Bulk Edit
  • Keywords needs-patch removed
  • Resolution set to invalid
  • Severity changed from major to normal
  • Status changed from reopened to closed
  • Summary changed from Breaks Tables if thead, #cb, .column-title, etc. is hidden when ajax is ran on screen using WP_List_Table to Quick Edit removes custom added edit columns on save

If at any point a table header column gets hidden and their is an ajax update, it completly breaks the tables...

Could you please create a new ticket for that?

The issue you described is different from the original issue, which was caused by a plugin.

#9 in reply to: ↑ 8 @codecandid
10 years ago

Replying to SergeyBiryukov:

If at any point a table header column gets hidden and their is an ajax update, it completly breaks the tables...

Could you please create a new ticket for that?

The issue you described is different from the original issue, which was caused by a plugin.

Sure thing Sergey . #29030

Last edited 10 years ago by SergeyBiryukov (previous) (diff)
Note: See TracTickets for help on using tickets.