Missing link to edit term objects of non-public taxonomy

[johnbillion]

Related to #18706. On the taxonomy screen for a non-public taxonomy, links to the posts belonging to each term are not present due to erroneous use of the taxonomy's 'public' attribute.

[johnbillion]

Patch - however this only works in conjunction with Sergey's patch on #18706. Should probably have merged them. Oh well.

[duck_]

From IRC:

I agree with "erroneous use of the taxonomy's 'public' attribute", but don't know why we would check the taxonomy's show_ui for a link to a list of posts (or other content). Surely we would want to check if the post_type has show_ui => true?

See 18722.2.diff​. Also includes removal of $post_type global and only adds $post_type to $args if != 'post'.

[duck_]

In [19383]:

Link the posts count on taxonomy list table for non-public taxonomies. Instead check if the post type has show_ui => true as we're linking to the post list table. Fixes #18722.

[nacin]

In [19385]:

Remove $post_type global usage from media list table. Correct $post_type to 'attachment' for upload screens. see #18722.

[duck_]

Replying to duck_:

Also includes removal of $post_type global

This causes a notice when adding new terms as get_current_screen()->post_type returns an empty string during the add-tag AJAX request, so get_post_type_object() returns null.

A check should be added before accessing ->show_ui, and we might want to go back to $post_type global too if the post count should be linked even for new terms with zero posts.

[nacin]

What about edit tag? Let's just revert that.

[duck_]

Replying to nacin:

What about edit tag? Let's just revert that.

Good point, see 18722.use-global.diff​.

[duck_]

In [19415]:

Go back to $post_type global as get_current_screen()->post_type is empty during add/edit-tag AJAX requests. Fixes #18722.

[coffee2code]

Example of making potentially restrictive if() fully permissive

[coffee2code]

Patch to help screen figure out its post_type

[coffee2code]

I think what @duck_ had there previously could be used with minor modification and without needing to revert to using the $post_type global again.

Is ​this line too restrictive? It's why the post_type couldn't be properly inferred. Currently, it only attempts to consider $_REQUEST['post_type'] for the post_type when WP_Screen::get() is called without an argument, which is essentially when set_current_screen() is called without an argument (i.e. for the current screen).

In related AJAX calls, set_current_screen() is called with an argument explicitly indicating the screen context. As such, $hook_name has a value and $_REQUEST is thus never consulted even though doing so would correctly set the post_type. In the aforementioned line, simply setting it to if ( true ) (or removing the if() from around the code it wraps) seems to work without notices. See 18722.no-global.1.diff​ for simple, minimal-change example (not intended as final patch).

So regardless of the value of $hook_name in WP_Screen::get(), couldn't we continue with further checking $_REQUEST if $post_type isn't yet set? See patch 18722.no-global.2.diff​ which:

• Removes use of global $post_type reintroduced in [19415]
• Consults $_REQUEST only if $post_type or $taxonomy aren't set
• Flattens two switch() blocks into one

Perhaps better filed as a new enhancement ticket for 3.4?

[nacin]

The issue is that WP_Screen is not necessarily the current screen. Only if we are relying on the global hook_suffix do we know that we can actually glean something off of the URL. Otherwise it may be a convert_to_screen() call for a meta box (for example) that doesn't even belong on that page.

I've thought about ways to tweak the architecture of WP_Screen to allow us to indicate when we *do* want to calculate things off $_REQUEST, because of the current order of operations prevents us from knowing at WP_Screen::get() time that we want it for the current screen. We had a usage of set_current_screen( $hook_name ) in an ajax request but found we could get rid of it, rather than fixing this root problem.

I think what we need is WP_Screen::ajax( $hook_name ), which will use ::get()'s innards. Definitely 3.4.