Quick Edit removes custom added edit columns on save

[sillybean]

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

[webord]

It's happening to me to.

I have installed the ​Yoast SEO Plugin.

It's not return the columns from the plugins.

[nacin]

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.

[nacin]

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.

[SergeyBiryukov]

Sounds like a duplicate of #18496.

[nacin]

		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.

[brasofilo]

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.

[codecandid]

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

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

[codecandid]

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