Page name won't work if the parent page has an attachment with the same name

[designsimply]

It's possible to create a page name that has the same name as an attachment page with the same parent. If you do that, the attachment page takes precedent and it's not possible to display the page with the matching name.

To reproduce:

1. Create a page, attach some images to it, save and publish
   
2. Create a child page with the same name as one of images attached to the parent page
   

---> Result: a page name and an attachment page name that are the same and it's not possible to view the page at ​http://example.com/parent_page_name/page_name/

Tested with r16708

Making the attachment post type hierarchical fixes it this my tests. Is there any reason attachment post types should not be hierarchical?

This is definitely duplicating another ticket somewhere. But I think this is the first time I've seen it well-explained and with a patch. :)

Making the attachment post type hierarchical fixes it this my tests. Is there any reason attachment post types should not be hierarchical?

Yes, attachments are not hierarchical because it doesn't make sense to link an attachment to another attachment.

We should find a better way to fix this.

I suspect the real fix here is to find out why we match attachment slugs when looking up root level pages

Found two additional cases where it's possible to add pages that conflict with auto-generated pages:

• author/EXISTING_BLOG_USER
  
• category/EXISTING_CATEGORY

This is in addition to the case originally reported where it's possible to add a page that conflicts with existing attachment pages names for the same parent page:

• PARENT_PAGE/ATTACHMENT_PAGE

fixed get_page_by_path()

Can't reproduce your problem with author and category though. More detailed steps?

Closed #16438 as a duplicate.

#19683 was closed as a duplicate, apparently root level pages were not susceptible to collisions prior to 3.3. This is might due to changes in get_page_by_path(), see #16687.

Replying to westi:

I suspect the real fix here is to find out why we match attachment slugs when looking up root level pages

get_page_by_path() queries for attachment as well as the specified post type.

Related #17170.

Replying to duck_:

apparently root level pages were not susceptible to collisions prior to 3.3.

Sorry for repeating that without double checking. It's wrong.

Closed #20612 as a duplicate.

This is super annoying. We should resolve this.

Closed #21008 as a duplicate.

Related: [6377], #3614

15665.patch​ compares found post type with the requested one before breaking the loop, to see if we can find an item that meets all other requirements and also has the same post type.

+1 for 3.5.

Here's a unit test which tests this bug. Comments gratefully accepted - particularly as this is the first WP test I've written.

15665-unit.patch​ executes the reproduction steps described in the bug; currently fails, passes with patch applied.

Just came across a little issue which I believe is related to this.

If I have a page "Rooms," for example, with child page "Amenities" as well as a CPT with 'rooms' as the rewrite slug (below), the child page /rooms/amenties/ will 404 as 'amenties' is expected to be part of the CPT

register_post_type('room', array(
	//...
	'rewrite' => array('slug' => 'rooms')
	//...
));

If unrelated, let me know, I'll check again for an existing ticket or open a new one.

I think we can simply call wp_insert_attachment() rather than actually upload a file for 15665-unit.patch​.

trepmal, that does not appear related.

Replying to nacin:

simply call wp_insert_attachment()

Looks like that works fine; updated in 15665-unit-2.patch​.

Closed #21216 as a duplicate.

Closed #21501 as a duplicate.

In [21845]:

In get_page_by_path(), attempt to return an item that has the same post type before returning an attachment with the same name. props SergeyBiryukov. tests in ​[UT1021]. fixes #15665.