Attachments are viewable from any permalink that matches their slug

[prorock]

I see one problem in WordPress, for example if you upload an images with name comments.png, all your url contain hide url like: /comments

example:
original post: yourdomain.com/myarticle
if you have in media gallery file with name comments.png url will be: yourdomain.com/myarticle/comments
or
yourdomain.com/myarticle2/comments
or
yourdomain.com/myarticle3/comments

and all this url's contain the same comment box.

my users report this problem, because if i share in twitter or g+ one link, many users redirect not to the post but to url with /comments in the end.

Adrian,

designmodo.com

This would likely also effect images named page, feed, or trackback as well.

Not sure what the problem is. My steps:

1. Switched permalink structure to /%postname%/.
2. Created and published a new post: /test8/
3. On Edit Post screen, uploaded comments.jpg image.
4. URL of the post is still the same (/test8/) and opens the post without a redirect.
5. URL of the uploaded image is /test8/comments/ and opens the image.

Sergey, try to create posts like /test9 and /test10 without upload any images and type in browser /test9/comments/ /test9/comments/ will appear the same image that in case of /test8/comments/

Ah, I see. Confirmed.

Good, waiting others for confirmation.

This seems to be a wider issue than what was originally reported. Basically, you can view an attachment by appending it's slug to the link for any post! To reproduce:

• Use pretty permalinks (the exact structure doesn't matter)
• Add an attachment to a post (e.g., with attachment URL /2012/01/30/my-post/my-attachment/)
• Now you can view that attachment by appending the attachment slug to any other post. For example /2012/01/01/hello-world/my-attachment/ or /2011/11/01/another-random-post/my-attachment/.

The name of the attachment doesn't matter.

I can reproduce this in WP 3.2 (and 3.3, trunk). Don't have an earlier version running at the moment.

In 3.3.1 is the same problem, so don't change version :)

Thanks

The version field is used to identify the earliest version at which the bug exists. Because it says 3.2 doesn't mean it doesn't exist in 3.3.

Sounds like something that should probably be handled by canonical.

Here's a patch for starters. It fixes the issue for me, but I'm not too familiar with canonical so there is probably a better/more correct way to do it.