Potential reference to unset variable in get_bulk_actions (WP_Posts_List_Table)

[sgrant]

get_post_type_object can return null in some cases, which causes a notice when current_user_can is called later in the function.

Attached a patch to check if delete_posts is set, and to only add actions if it is. Thanks!

[sgrant]

Add isset check before referencing

[Fab1en]

Hi sgrant

Could you please provide a the way you have triggered this bug, so that I can reproduce it ?

And I think you made a mistake in your patch : $post_type_obj->delete_posts will never exist, its $post_type_obj->cap->delete_posts that has to be checked.

[chriscct7]

Updated patch with additional checks for edit_posts cap as well as empty post_type_obj variable.

[pento]

It'd be good to have some steps to reproduce this.

[callumbw95]

Hi @sgrant,

As we haven't seen any progress on this regarding steps to recreate the problem, I'm applying the close tag.

Feel free to respond and remove it if you'd prefer to keep the discussion going. For example, you might try installing the ​Test Reports plugin and submitting a bug report. This will help us pinpoint any external factors contributing to the issue, allowing the community and me to offer more effective assistance. 😃

WP_Posts_List_Table::get_bulk_actions() passes the result of get_post_type_object() straight into current_user_can() without checking it. get_post_type_object() returns null for an unregistered post type, so both capability checks in the method read ->cap off null. On PHP 8 that is a warning, and before PHP 8 it was a notice about an undefined property, which is what the reporter described.

The ticket has sat with a close keyword for years because nobody could supply reproduction steps. Here they are, and they are reproducible on trunk.

A screen can hold a post type that is not registered. wp_ajax_fetch_list() builds a list table from a screen id taken out of the request:

$wp_list_table = _get_list_table( $list_class, array( 'screen' => $_GET['list_args']['screen']['id'] ) );

convert_to_screen() does not verify that the post type exists. The edit branch of WP_Screen::get() only appends the post type to the id, so any screen id of the form edit-<unknown> produces a WP_Posts_List_Table whose screen->post_type is unregistered. get_bulk_actions() is then reached through bulk_actions(), and the warning is raised.

The reproduction is now a unit test rather than a manual recipe. On unmodified trunk it fails with:

Tests_Admin_wpPostsListTable::test_get_bulk_actions_with_unregistered_post_type
Attempt to read property "cap" on null
src/wp-admin/includes/class-wp-posts-list-table.php:436

The change returns early when no post type object is available. With no post type there are no valid bulk actions to offer, so an empty array is the correct result, and it matches the direction the ticket owner already suggested in 31199-2.patch ("additional checks for edit_posts cap as well as empty post_type_obj variable").

Scope notes:

• Only get_bulk_actions() is touched. The file has other unguarded uses of get_post_type_object() in ajax_user_can(), no_items(), extra_tablenav() and inline_edit(). Those are deliberately left alone, since each is a separate question about which screen states the list table is expected to support, and folding them in would make this hard to review. Happy to follow up on them separately if that is wanted.
• The existing behaviour for a registered post type is unchanged, and that is pinned by a second test rather than left implied. It asserts the edit and trash actions are still returned for page, and it passes both before and after the change.
• The early return keeps the edit_posts and delete_posts capability checks exactly as they are, so a user who cannot edit or delete still gets the same actions they do today.

Use of AI Tools

AI assistance: Yes
Tool(s): Claude
Model(s): Sonnet
Used for: test cases, code review