Slug for non-public post type is working

[webzunft]

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 ​http://example.com/book.
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.

[DrewAPicture]

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.