WP_List_Table::get_columns does not work for plugins

[ptahdunbar]

Creating a new table based on the WP_List_Table class does not work as the get_columns method is not being called.

The problem is when WP_List_Table::get_column_info() calls get_column_headers() instead of $this->get_columns() where all the column data is stored.

Moving the filter manage_*_columns from get_column_headers() into WP_List_Table::get_column_info() along with passing $this->get_columns() fixes this issue.

[scribu]

The constructor in WP_List_Table adds the get_columns() method as filter with priority 0.

This is for backwards compatibility with older plugins that use the filter directly to register columns for new screens.

[scribu]

The likely problem is that get_column_headers() is called before My_Plugin_List_Table is instantiated.

[scribu]

my-list-table-plugin.php creates an admin screen and uses an example list table class semi-successfully.

The ajax doesn't work however.

[scribu]

Example list table class

[scribu]

Example plugin that uses list table class

[scribu]

I've only needed to hook into 'get_list_table_*'.

my-list-table-plugin.php now succesfully registers a custom list table class.

[manutdotcom]

remove array() arg from apply_filters

[manutdotcom]

When the array() argument is removed from line 24 (see screen.diff attachment), the table does tabulate properly without the need of initializing the WP_List_Table class before the page is loaded using add_action( "load-$screen_id", array( $this, '_init_list_table' ) ) as recommended in my-list-table-plugin.php above. The WP_List_table class can be initialized inside the function that was declared for add_menu_page().

Then I would be able to dynamically render different tables according to the GET variable. Useful for tabbed pages.

I was wondering since get_columns() do not require an input argument, maybe we could remove array() from line 24?

[scribu]

In the meantime, WP_List_Table has become internal i.e. is not recommended to be used directly by plugins at this time (WP 3.3).

With this in mind, feel free to open a new ticket.

[scribu]

But before that, see #17615 and #18449

[manutdotcom]

Thanks, in the meantime, I'll just manually define $this->_column_headers instead of it being automatically populated.

[markoheijnen]

What does of means that it is private. This class is a brilliant asset a developer can use since you want the same look in your plugin as WordPress itself.

Is the code most likely to change? Some information here can be handy for developers who want to use it.

[dd32]

Replying to markoheijnen:

What does of means that it is private. This class is a brilliant asset a developer can use since you want the same look in your plugin as WordPress itself.

The private status in this case means exactly what Private access means in applications "This should only be used by the core application at this point in time". It'll be rehashed elsewhere, but put basically: Don't use this while it's Private and expect core to retain compatibility in future releases, It'll be changed and will most likely break whatever you're currently doing with it in a million piece.

It's going to be a useful functionality to Plugin developers, We're just not quite at the point where we can offer it up to developers.

[pcfreak30]

This still appears to be an issue. I tracked it down in admin.php -> admin-header.php -> $current_screen->render_screen_meta() -> show_screen_options() -> get_column_headers.

get_column_headers gets called in the header before the table can even be created. Due to get_column_headers using a static, it can not be unset and causes empty result.

Only workaround I found was hooking admin_init, running set_current_screen(), creating the table in a private class property then accessing it on the plugins menu hook to render.

[netweb]

Moving reopened tickets without a milestone back to Awaiting Review for review

[davidbaumwald]

This still appears to be an issue. $columns are not being defined when extending WP_List_Table in a plugin.

[johnwatkins0]

Attaching https://core.trac.wordpress.org/attachment/ticket/15386/15386.diff. Also via GitHub: ​https://patch-diff.githubusercontent.com/raw/WordPress/wordpress-develop/pull/165.diff

Description of the change

This allows the filter in the get_column_headers function to be applied multiple times during page execution. Previously this function used a static variable to ensure the filter was only applied once per screen object per page load.

That static variable is not needed. The function doesn't need to maintain internal state, and I don't see any reason that the performance-related use cases for static function variables apply here more than elsewhere. I'm happy to discuss this further.

Test steps

Before pulling these changes, put this in a file in wp-content/plugins.

<?php
/**
 * Plugin Name: My List Table Plugin
 */

add_action( 'admin_menu', 'my_list_table_plugin_init' );

function my_list_table_plugin_init() {
	add_menu_page( 'Test', 'Test', 'manage_options', 'test', 'my_list_table_plugin_display' );
}

function my_list_table_plugin_display() {
	$table = _get_list_table( 'WP_Comments_List_Table' );
	$table->views();
	$table->prepare_items();
	$table->display();
}

Also make sure your environment has at least one comment.

Before

Activate the plugin. Visit /wp-admin/admin.php?page=test in your local environment. Note that the table displays without the expected table rows.

After

After pulling these changes, visit that page again. The table rows should now display.

Further considerations

If this change were merged, wouldn't it mean that at least the WP_List_Table class and maybe also _get_list_table would no longer need to be private? If so, how would I deprecate _get_list_table in favor of get_list_table? Do we have documentation on that somewhere?

I feel the API around these list tables could be improved, however, and maybe even Gutenbergized. If others agree, then maybe that class and function should stay private for now.

[chaion07]

Thanks @ptahdunbar for reporting this issue. We reviewed the ticket during a ​recent Core Triage session. Based on the feedback received from the team, we feel the need for a refresh for the patch and a owner for the ticket. However, we would leave as it is for now and hopefully someone possibly will own the ticket for a better and realistic approach to this. Cheers!