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.

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.

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

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

The ajax doesn't work however.

Example list table class

Example plugin that uses list table class

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

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

remove array() arg from apply_filters

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?

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.

But before that, see #17615 and #18449

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

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.

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.

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.

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