Opened 4 years ago
Last modified 4 years ago
#50080 new defect (bug)
wp_set_post_tags() adds terms to post types that don't support the term's taxonomy
Reported by: | paulschreiber | Owned by: | |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | normal | Version: | 2.3 |
Component: | Taxonomy | Keywords: | reporter-feedback |
Focuses: | Cc: |
Description
Setup:
(1) Register a custom post type without taxonomy support
add_action( 'init', function() {
register_post_type(
'foobar',
[
'labels' => [
'name' => __( 'foobars' ),
'singular_name' => __( 'foobar' ),
],
'public' => false,
'publicly_queryable' => true,
'has_archive' => false,
'hierarchical' => false,
]
);
} );
(2) Create a tag
wp_insert_term( 'green', 'post_tag' );
=> array(2) {
["term_id"]=>
int(4)
["term_taxonomy_id"]=>
int(4)
}
(3) Create a post
wp_insert_post( [ 'post_type' => 'foobar' ] );
=> int(8)
(4) Assign the term to the post
wp> wp_set_post_tags( 8, 'green' );
=> array(1) {
[0]=>
string(1) "4"
}
Expected behaviour is a WP_Error
object, since the CPT foobar
does not support the post_tag
taxonomy.
(5) Get the tags for the post
wp> wp_get_post_tags(8)
=> array(1) {
[0]=>
object(WP_Term)#1955 (10) {
["term_id"]=>
int(4)
["name"]=>
string(5) "green"
["slug"]=>
string(5) "green"
["term_group"]=>
int(0)
["term_taxonomy_id"]=>
int(4)
["taxonomy"]=>
string(8) "post_tag"
["description"]=>
string(0) ""
["parent"]=>
int(0)
["count"]=>
int(1)
["filter"]=>
string(3) "raw"
}
}
Expected behaviour is an empty array.
Change History (2)
#2
@
4 years ago
On The Undefeated, we noticed some posts from a private CPT showing up on tag archive pages. We eventually tracked it down to the private CPT getting tags via some filter/actions.
In addition to putting broken links on the tag archive page, was an inadvertent (and in this case harmless) information disclosure. Such a disclosure could have worse consequences for others.
Note: See
TracTickets for help on using
tickets.
wp_set_post_tags()
/wp_set_post_categories()
are wrappers forwp_set_object_terms()
which indeed don't verify the type of the object ID and never have. Neither doeswp_get_object_terms()
.How did you notice this? Is there a specific bug that this behaviour is causing?