Make WordPress Core

Opened 8 years ago

Closed 8 months ago

#36979 closed defect (bug) (invalid)

Slug for non-public post type is working

Reported by: webzunft's profile webzunft Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.5.2
Component: Posts, Post Types Keywords:
Focuses: Cc:


When creating a non-public post type with 'public'=>false set and a slug given by accident too, there is still a url with that slug created.

How to reproduce this?

Use this adjusted example from the codex:

add_action( 'init', 'codex_book_init' );
function codex_book_init() {
        $labels = array(
                'name'               => _x( 'Books', 'post type general name', 'your-plugin-textdomain' ),
                'singular_name'      => _x( 'Book', 'post type singular name', 'your-plugin-textdomain' ),

        $args = array(
                'labels'             => $labels,
                'description'        => __( 'Description.', 'your-plugin-textdomain' ),
                'public'             => false,
                'publicly_queryable' => false,
                'show_ui'            => true,
                'show_in_menu'       => true,
                'query_var'          => true,
                'rewrite'            => array( 'slug' => 'book' ),
                'capability_type'    => 'post',
                'has_archive'        => true,
                'hierarchical'       => false,
                'menu_position'      => null,
                'supports'           => array( 'title', 'editor', 'author', 'thumbnail', 'excerpt', 'comments' )

        register_post_type( 'book', $args );

I only adjusted public and publicly_queryable to false.
After flushing the permalinks, I can access the url
WordPress seems to identify this as the home page and the page would also be indexable by search engines.

I would expect this to give a 404 error since the public parameter is set to false.

When there is no rewrite resp. slug parameter given then it works as expected, so this is not critical and there is no reason to use the slug either, but a developer could still forget – as I did so this is how I found out.

I checked the register_post_type function, but couldn’t find a quick fix for it there.

Change History (1)

#1 @DrewAPicture
8 months ago

  • Resolution set to invalid
  • Status changed from new to closed

This is expected behavior and is clearly documented on the $rewrite argument in register_post_type():

Triggers the handling of rewrites for this post type. To prevent rewrite, set to false.

Anything other than an explicit false will result in rewrites being created.

Note: See TracTickets for help on using tickets.