WordPress.org

Make WordPress Core

#42926 closed defect (bug) (wontfix)

Archive page don't work

Reported by: sebastian.pisula Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.9.1
Component: Posts, Post Types Keywords:
Focuses: Cc:

Description

Hi,

I want register CPT "FAQ". All is OK but this CPT will be have only archive without singular page. I register CPT on init hook:

<?php
register_post_type( 'ic-faq', [
                        'label'               => 'FAQ',
                        'supports'            => array( 'title', 'editor' ),
                        'hierarchical'        => false,
                        'public'              => true,
                        'show_ui'             => true,
                        'show_in_menu'        => true,
                        'menu_position'       => 5,
                        'menu_icon'           => 'dashicons-editor-help',
                        'show_in_admin_bar'   => true,
                        'show_in_nav_menus'   => false,
                        'can_export'          => true,
                        'has_archive'         => 'faq',
                        'exclude_from_search' => true,
                        'publicly_queryable'  => false,
                        'capability_type'     => 'post',
                ] );

After I add new post in FAQ "view post" in table row is disable and this is OK but in Admin Bar I have button "View posts" (with url http://example.com/faq/) and when I click then I was redirected to home page. I think that this is bug and this problem have two way to resolve:

  1. In admin bar link "view posts" should be removed;
  2. Archive should work ;-)

I think that archive should work. Maybe I'm doing something bad? Or maybe this work differently than I think?

Change History (1)

#1 @dd32
18 months ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Hi @sebastian.pisula,

Two things

  • Make sure you flush the rewrite rules to have archives become available, this isn't (and won't be) done automatically
  • By setting publicly_queryable to false but having the rest of the parameters as public results in this scenario - this is an extreme edge case that doesn't deserve any developers time. It should be assumed that if you set it up in this manner, you've got other code to handle that scenario and have deliberately set it such.

I'm closing this as wontfix as anything we do change would most likely be directly against what a developer was attempting to achieve.

Note: See TracTickets for help on using tickets.