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

[thee17]

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

[SergeyBiryukov]

Not sure what the problem is. My steps:

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

[prorock]

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/

[SergeyBiryukov]

Ah, I see. Confirmed.

[prorock]

Good, waiting others for confirmation.

[solarissmoke]

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.

[prorock]

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

Thanks

[solarissmoke]

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.

[nacin]

Sounds like something that should probably be handled by canonical.

[solarissmoke]

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.

[chriscct7]

Patch still looks good to go, but the severity of this issue isn't "major", as it doesn't really break anything. Downgrading to normal.

[wonderboymusic]

In 34272:

Canonical: redirect URLs that match an attachment masked on the wrong URL to the attachment link for the matched attachment.

Props solarissmoke.
Fixes #19918.

[swissspidy]

[34272] broke attachment endpoints

To reproduce:

1. Add a rewrite endpoint, e.g. by using add_rewrite_endpoint( 'embed', EP_ALL ); or just add_rewrite_endpoint( 'embed', EP_ATTACHMENT );
2. Upload an attachment to a post.
3. Visit the attachment URL with that endpoint, e.g. http://example.org/my-awesome-post/sample-attachment/embed/.
4. redirect_canonical redirects you to http://example.org/my-awesome-post/sample-attachment/

[wonderboymusic]

In 34643:

Canonical: after [34272], don't redirect rewrite endpoints on attachment URLs when pretty permalinks are enabled.

Fixes #19918.

[tellyworth]

These two recent commits triggered a circular redirect in some themes on wp.com. Those themes filter attachment_link to add a fragment #main, and that interacts with the new code to redirect back to the same url.

For an example, see suburbia_enhanced_image_navigation in ​https://wpcom-themes.svn.automattic.com/suburbia/functions.php.

I checked with our theme team, and they think it's reasonable behaviour for a theme to do that. It's also likely that other, non-Automattic themes do something similar.

I'm not really sure what the solution is, or even if there could be a third factor interacting, but I did confirm that reverting those two commits stops the circular redirect from happening.

[tellyworth]

Fixes a potential circular redirect issue.

[tellyworth]

Replying to tellyworth:

These two recent commits triggered a circular redirect in some themes on wp.com. Those themes filter attachment_link to add a fragment #main, and that interacts with the new code to redirect back to the same url.

I'm reasonably convinced that this is a general problem in redirect_canonical(). If any of the functions used to generate a canonical URL (such as get_permalink()) are filtered to add a #fragment, this causes the circular redirect detection logic to fail.

attachment:19918-circular-fragment.diff​ prevents this from happening. It fixes the attachment issue, and shouldn't prevent redirecting to a URL that contains a fragment, which is probably a valid use case.

[wonderboymusic]

19918.2.diff​ fixes the patch, which had the wrong var in it, $redirect_url, which was blowing up unit tests.

[boonebgorges]

@wonderboymusic New function could use a @since annotation, but otherwise +1 from me on 19918.2.diff​

[wonderboymusic]

In 35770:

Canonical: introduce strip_fragment_from_url() and use when comparing URLs in redirect_canonical().

Props tellyworth.
Fixes #19918.