#18993 closed defect (bug) (invalid)
is_post_type_archive() returns true in the admin area
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 3.3 |
Component: | Administration | Keywords: | close |
Focuses: | Cc: |
Description
When viewing a custom post type listing screen in the admin area, is_post_type_archive()
returns true.
The offending code (as of r18999) starts at line 1568 in wp-includes/query.php
.
A quick fix would be to stick an is_admin()
check in there, but I'm not sure that's the right thing to do so I'll leave it up to someone else to patch.
Change History (10)
#2
in reply to:
↑ 1
@
13 years ago
Happens in 3.2.1 too (at least is_search()
and is_date()
), so not a regression.
#3
@
13 years ago
The admin is really just another loop.
For this reason, a lot of loop modifying functions I see have a if ( is_admin() || !is_main_query() ) return $input;
short circuit. This is expected behaviour I believe.. is_post_type_archive()
doesn't really feel like a function you'd expect to use outside of a template loop, but it's naming is just for the most obvious use-case..
#4
@
13 years ago
- Keywords needs-patch removed
- Milestone Awaiting Review deleted
- Resolution set to invalid
- Status changed from new to closed
This is consistent with all the rest of the conditional tags, which aren't expected to be used in the admin area.
The correct approach here is either what dd32 mentioned, or checking is_admin() before even calling add_action or add_filter().
#5
follow-up:
↓ 6
@
12 years ago
- Resolution invalid deleted
- Status changed from closed to reopened
Re-opening this, because I was about to file the exact same bug report.
This is consistent with all the rest of the conditional tags, which aren't expected to be used in the admin area.
I agree that conditional tags aren't expected to be used in the admin area, but I disagree that this is consistent with the rest of the conditional tags. is_post_type_archive() is analogous to is_archive(), which returns false in the same scenario.
Specifically, this example code causes unexpected behaviour when viewing the custom post type "Edit" page in the admin ( example.com/wp-admin/edit.php?post_type=pmc_gallery ):
// Filter to add pmc_gallery posts to home, category, and tag archives add_filter( 'pre_get_posts', function( $query ) { if ( ( is_home() || is_archive() ) && $query->is_main_query() ) { $query->set( 'post_type', array( 'post', 'pmc_gallery' ) ); } return $query; } ); // Register the pmc_gallery custom post type add_action( 'init', function() { register_post_type( 'pmc_gallery', array( 'labels' => array( 'name' => 'Galleries', ), 'public' => true, 'show_ui' => true, 'capability_type' => 'post', 'rewrite' => array( 'slug' => 'gallery', ), 'query_var' => true, 'supports' => array( 'title', 'editor', 'comments', 'revisions', 'thumbnail', 'author', 'excerpt' ), 'publicly_queryable' => true, 'show_ui' => true, 'show_in_menu' => true, 'taxonomies' => array( 'post_tag', 'category', ), 'has_archive' => true, 'hierarchical' => false, 'menu_position' => 5, ) ); } );
Expected behaviour:
pmc_gallery posts are shown on the home page and archive pages, along with regular posts.
Actual behaviour:
As above, plus /wp-admin/edit.php?post_type=pmc_gallery also shows regular posts listed along with pmc_gallery posts, although the counts at the top of the screen match only the pmc_gallery post counts.
Reading the code where $query-> is_post_type_archive is set to true in /wp-includes/query.php this behaviour seems like an accident.
#6
in reply to:
↑ 5
;
follow-up:
↓ 7
@
12 years ago
- Keywords close added
- Milestone set to Awaiting Review
Replying to mintindeed:
is_post_type_archive() is analogous to is_archive(), which returns false in the same scenario.
is_post_type_archive()
returns true if post_type
query variable is set, which is the case in your example. And is_archive()
then actually returns true as well:
http://core.trac.wordpress.org/browser/tags/3.4.2/wp-includes/query.php#L1572
As noted above, if you don't want your filter functions to run in the admin, the solution is to add is_admin()
check.
#7
in reply to:
↑ 6
;
follow-up:
↓ 8
@
12 years ago
Replying to SergeyBiryukov:
Replying to mintindeed:
is_post_type_archive() is analogous to is_archive(), which returns false in the same scenario.
is_post_type_archive()
returns true ifpost_type
query variable is set, which is the case in your example. Andis_archive()
then actually returns true as well:
http://core.trac.wordpress.org/browser/tags/3.4.2/wp-includes/query.php#L1572
As noted above, if you don't want your filter functions to run in the admin, the solution is to add
is_admin()
check.
I still find it inconsistent. When you're on edit.php for non-custom post types (e.g., post), is_archive is false. That's the point I was trying to illustrate.
As far as I can tell, no other template conditional tags return true in the admin.
#8
in reply to:
↑ 7
@
12 years ago
- Milestone Awaiting Review deleted
- Resolution set to invalid
- Status changed from reopened to closed
Replying to mintindeed:
As far as I can tell, no other template conditional tags return true in the admin.
Here are some URLs that you can reach by clicking on various links in /wp-admin/edit.php:
/wp-admin/edit.php?tag=test -> is_archive, is_tag, is_admin /wp-admin/edit.php?category_name=uncategorized -> is_archive, is_category, is_admin /wp-admin/edit.php?s&post_status=all&post_type=post&action=-1&m=201210&cat=1&paged=1&mode=list&action2=-1 -> is_archive, is_date, is_month, is_category, is_admin
The query flags do not and should not take into account if you're in wp-admin or not.
In fact, other conditionals such as
is_search()
andis_date()
also return true when searching or viewing posts by date in the admin area. I'm not sure if this is expected behaviour or not.