Opened 10 years ago
Last modified 14 months ago
#15386 reopened defect (bug)
WP_List_Table::get_columns does not work for plugins
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | Awaiting Review | Priority: | high |
Severity: | major | Version: | 3.1 |
Component: | General | Keywords: | has-patch |
Focuses: | Cc: |
Description
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.
Attachments (5)
Change History (24)
#4
@
10 years ago
The likely problem is that get_column_headers() is called before My_Plugin_List_Table is instantiated.
#5
@
10 years ago
- Keywords needs-patch added; has-patch close removed
my-list-table-plugin.php creates an admin screen and uses an example list table class semi-successfully.
The ajax doesn't work however.
#8
@
10 years ago
- Milestone 3.1 deleted
- Resolution set to worksforme
- Status changed from accepted to closed
I've only needed to hook into 'get_list_table_*'.
my-list-table-plugin.php now succesfully registers a custom list table class.
#9
@
9 years ago
- Cc manutdotcom added
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?
#10
@
9 years ago
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.
#12
@
9 years ago
Thanks, in the meantime, I'll just manually define $this->_column_headers instead of it being automatically populated.
#13
follow-up:
↓ 14
@
9 years ago
- Cc marko@… added
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.
#14
in reply to:
↑ 13
@
9 years ago
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.
#15
@
4 years ago
- Resolution worksforme deleted
- Status changed from closed to reopened
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.
#16
@
4 years ago
- Milestone set to Awaiting Review
Moving reopened tickets without a milestone back to Awaiting Review
for review
#17
@
14 months ago
This still appears to be an issue. $columns
are not being defined when extending WP_List_Table in a plugin.
This ticket was mentioned in PR #165 on WordPress/wordpress-develop by johnwatkins0.
14 months ago
#19
@
14 months ago
- Keywords has-patch added; needs-patch removed
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.
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.