Opened 14 years ago
Last modified 22 months ago
#15386 reopened defect (bug)
WP_List_Table::get_columns does not work for plugins
Reported by: | ptahdunbar | Owned by: | scribu |
---|---|---|---|
Milestone: | Future Release | Priority: | high |
Severity: | major | Version: | 3.1 |
Component: | Administration | Keywords: | has-patch has-unit-tests dev-feedback close |
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 (8)
Change History (37)
#4
@
14 years ago
The likely problem is that get_column_headers() is called before My_Plugin_List_Table is instantiated.
#5
@
14 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
@
14 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
@
13 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
@
13 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
@
13 years ago
Thanks, in the meantime, I'll just manually define $this->_column_headers instead of it being automatically populated.
#13
follow-up:
↓ 14
@
13 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
@
13 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
@
8 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
@
8 years ago
- Milestone set to Awaiting Review
Moving reopened tickets without a milestone back to Awaiting Review
for review
#17
@
5 years 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.
5 years ago
#18
#19
@
5 years 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 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.
This ticket was mentioned in Slack in #core by chaion07. View the logs.
3 years ago
#21
@
3 years ago
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!
This ticket was mentioned in PR #3735 on WordPress/wordpress-develop by @bgoewert.
2 years ago
#22
- Keywords has-unit-tests added
Trac ticket: https://core.trac.wordpress.org/ticket/15386
#23
@
2 years ago
I created a refreshed PR. While this fixed the headers/rows not displaying as described in comment 19, it also produced one phpunit failure seen here.
Test Report
Patch tested: PR 3735
Environment
- OS: Pop!_OS 22.04
- Localhost: wordpress-develop & Docker Desktop
- WordPress: trunk
- Browser: Firefox 107, Chrome 108, GNOME Web 43 (WebKit 2.38.1)
- Theme: Twenty Twenty-Two
- Active Plugins: my-list-table-plugin-15386.php
Steps to Reproduce
- Download and install my-list-table-plugin-15386.php.
- Ensure there is at lease one comment.
- Navigate to
/wp-admin/options-general.php?page=test
- Notice that the table displays without any headers or rows.
- Apply or Checkout PR 3735.
- Refresh the test page
/wp-admin/options-general.php?page=test
Expected Results
- Table list displays comment headers and rows.
Actual Results
- ✅ I can see headers/rows.
Supplemental Artifacts
Before applying patch
After applying patch
This ticket was mentioned in Slack in #core by bgoewert. View the logs.
2 years ago
#25
@
2 years ago
- Component changed from General to Administration
- Milestone changed from Awaiting Review to 6.2
#27
@
2 years ago
- Keywords dev-feedback close added
The example in comment:8 no longer works as it stands. I've attached an updated version of this example.
According to the class reference, developer usage of WP_List_Table
is still in limbo (even though it is widely used). And there is plenty of documentation on it's usage.
WP_List_Table
was taken out of private status in 6.1 [54378] #18449
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.