url_to_postid() doesn't resolve attachments when rewrite rules are disabled

[anonymized_154007]

The code of url_to_postid() is pretty clear in the case of disabled rewrite rules: all URLs not using the p=N, page_id=N or attachment_id=N forms are not parsed and the function return 0. That make sense.

Now there is a special case for attachments. Attachments can be saved under a the /wp-content/uploads/year/month/ folder structure while rewrite rules are disabled at the same time.

This means there is a missed opportunity for url_to_postid() to resolve attachment's URLs of the long-form when rewrite rules are disabled.

This was tested and reproduced on WordPress 3.1.

[anonymized_154007]

FYI, this ​issue emerged from a forum topic.

There ​you'll find a solution under the form of a custom method:

function get_attachment_id_from_src ($image_src) {
  global $wpdb;
  $query = "SELECT ID FROM {$wpdb->posts} WHERE guid='$image_src'";
  $id = $wpdb->get_var($query);
  return $id;
}

The code above may be tightly integrated to url_to_postid() to solve image URLs to post IDs.

[anonymized_154007]

Also, ​as discussed in the forum, we may consider to distinguish:

• image URLs (like http://domain.com/wp-content/uploads/month/year/attachment-filename.jpg) and
• attachment URLs (like http://domain.com/year/month/post-slug/attachment-slug/)

as two different classes of content. With this hypothesis in mind, we can then decide that image URLs are not meant to be translated to post IDs by url_to_postid(). In which case this bug report can be closed as invalid.

But I quite disagree with this idea of distinguishing these two classes of URLs. Why ? Look at a method like wp_get_attachment_url(). It returns what I called above an "image URL". Yet the method is named with the "attachment" keyword. To me this indicate either:

• a framework inconsistency (which should be solved by renaming these kind of methods),
• or that my bug report is valid and that url_to_postid() should be able to resolve what I called "image URLs".

[anonymized_154007]

Another clue of serious inconsistency: ​get_attachment_link() return what I called the "attachment URL" (= a pretty permalink URL). Yet it is named using the "link" keyword. These "links" are currently well supported by the url_to_postid() method. So why the latter is not named link_to_postid() ? :)

[c3mdigital]

I can't think of a use case for needing the attachment_id when you have the full url to the actual image, maybe to get the attachment meta data? I'm closing but if anyone has a use case that I'm missing please reopen.

[MikeSchinkel]

Replying to c3mdigital:

I can't think of a use case for needing the attachment_id when you have the full url to the actual image, maybe to get the attachment meta data? I'm closing but if anyone has a use case that I'm missing please reopen.

One reason you mention is attachment meta data.

Further, most (all?) of the wp_get_attachment() functions expect an attachment post ID, so I can very much see how this would be useful for more advanced WordPress development, for example to parse URLs out of user entered content to match up with attachments or to parse the URL out of a feed for a site that has its database on the same MySQL server as the site with running, and to determine it's ID in the other site's database.

(We are doing both of these on my current project.)

However, the implementation of this function needs to be more complex than to just check against the guid because that can fail.

[ocean90]

Related: [24548]/#24458, ticket:23831:8

[c3mdigital]

Replying to MikeSchinkel:

Replying to c3mdigital:

I can't think of a use case for needing the attachment_id when you have the full url to the actual image, maybe to get the attachment meta data? I'm closing but if anyone has a use case that I'm missing please reopen.

One reason you mention is attachment meta data.

Further, most (all?) of the wp_get_attachment() functions expect an attachment post ID, so I can very much see how this would be useful for more advanced WordPress development, for example to parse URLs out of user entered content to match up with attachments or to parse the URL out of a feed for a site that has its database on the same MySQL server as the site with running, and to determine it's ID in the other site's database.

(We are doing both of these on my current project.)

However, the implementation of this function needs to be more complex than to just check against the guid because that can fail.

After thinking about this more I agree. I also agree that using guid is not a good idea. I've come up with a patch that works nicely and will get the post or attachment ID of any attachment image.

The basic premise is checking if the url has an image extension then parsing it and extracting the string that would be save in postmeta as _wp_attached_file It also checks if it is a resized image and slices out the width x height bits.

[c3mdigital]

Get post_id if url is attachment image

[MikeSchinkel]

Replying to c3mdigital:

After thinking about this more I agree. I also agree that using guid is not a good idea. I've come up with a patch that works nicely and will get the post or attachment ID of any attachment image.

Great!

The basic premise is checking if the url has an image extension then parsing it and extracting the string that would be save in postmeta as _wp_attached_file It also checks if it is a resized image and slices out the width x height bits.

Nice work.

[MikeSchinkel]

Patched refreshed and refactored

[wonderboymusic]

If you want url_to_postid() to fall back to attachments? 16830.diff​

If you just want the ability to parse attachment URLs and retrieve a post ID? Since [29029]

[swissspidy]

I tend to prefer using url_to_postid and attachment_url_to_postid separately (i.e. wontfix). 16830.diff​ in general looks good though, but needs unit tests.