WordPress.org

Make WordPress Core

Opened 16 months ago

Last modified 16 months ago

#44773 new defect (bug)

Non Existing Child Page of Custom Post Redirects Instead of 404

Reported by: Asitha Owned by:
Milestone: Awaiting Review Priority: normal
Severity: critical Version: 4.9.8
Component: Rewrite Rules Keywords: needs-patch
Focuses: Cc:
PR Number:

Description

Steps to reproduce:

  1. Register Custom Post Type with hierarchical set to true (We'll call it events)
  2. Create the following structure in the CPT:
  • Test
  • Test 2
    • Child (Child of Test 2)
  1. Go to https://localhost/events/test/child and this will redirect you to https://localhost/events/test-2/child instead of returning a 404.

Extra Step:
If you create a normal page of "Test" and try to navigate to https://localhost/test/child, it will redirect to https://localhost/test-2/child.

All this was done on vanilla WordPress on Twenty Seventeen theme.

function register_my_cpts_events() {

	/**
	 * Post Type: Events.
	 */
	
	$labels = array(
		"name" => __( "Events", "" ),
		"singular_name" => __( "Event", "" ),
	);
	
	$args = array(
		"label" => __( "Events", "" ),
		"labels" => $labels,
		"description" => "Event overview and resource pages",
		"public" => true,
		"hierarchical" => true,
		"menu_icon" => "dashicons-calendar-alt",
		"supports" => array( "title", "editor", "thumbnail", "excerpt", "revisions", "page-attributes" ),
	);
	
	register_post_type( "events", $args );
}

add_action( 'init', 'register_my_cpts_events' );
		

Change History (2)

#1 @Asitha
16 months ago

  • Summary changed from Non Existing Child Page Redirects Instead of 404 to Non Existing Child Page of Custom Post Redirects Instead of 404

#2 @shariqkhan2012
16 months ago

I just had a cursory look and it appears that the problem could be in the function redirect_guess_404_permalink in file wp-includes/canonical.php.

For the case mentioned in the bug description the query comes out to be:

select * from $wpdb->posts where post_name like 'child' and post_type='events' and post_status='publish'

I am yet to do a more detailed debugging, but it looks odd to me why the query does not put the constraint of post_parent in the where condition.

Because of the missing post_parent clause, the query returns the first post it gets which has a slug 'child', which is clearly not correct in this case.

I am new to debugging core, so I don't have the faintest idea of the reason behind this, and what elase could break if we add the post_parent condition-check.

Need feedback for this.

Note: See TracTickets for help on using tickets.