Make WordPress Core

Opened 6 years ago

Closed 6 years ago

#42926 closed defect (bug) (wontfix)

Archive page don't work

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



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:

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 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
6 years 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.