Get an attachment ID by URL in WordPress

We all know you can use wp_get_attachment_url() to return an attachment’s URL by passing in the ID, but what about the reverse scenario?

There are a lot of long-winded examples of how to get an attachment ID by URL floating around the interwebs. Most of them limit results to only returning images or use expensive DB queries. Really, there should be a function for this in core, but there isn’t.

Needless to say, I wasn’t really happy with any of the solutions I found people using, so I decided to take a stab at it.

Below is the most lightweight method I’ve come up with (so far) to get an attachment ID by passing through an attachment URL.

Example usage

Just as an example, this would echo the attachment ID integer of test-image.jpg onto the page:

<?php echo fjarrett_get_attachment_id_by_url( 'http://frankiejarrett.com/wp-content/uploads/2013/05/test-image.jpg' ) ?>

This would echo the same result as above because we are ignoring www usage in the URL being passed through:

<?php echo fjarrett_get_attachment_id_by_url( 'http://www.frankiejarrett.com/wp-content/uploads/2013/05/test-image.jpg' ) ?>

This would echo nothing, because the image doesn’t exist in the WordPress uploads directory:

<?php echo fjarrett_get_attachment_id_by_url( 'http://frankiejarrett.com/foo/test-image.jpg' ) ?>

And finally, this would also echo nothing because the URL of the file is pointing to an external domain:

<?php echo fjarrett_get_attachment_id_by_url( 'http://www.anotherdomain.com/wp-content/uploads/2013/05/test-image.jpg' ) ?>

Conclusion

We managed to fetch an attachment ID in just a few lines of code with no expensive DB queries! Awesome 8-)

Now you can do cool things like turn a URL into an absolute path:

<?php
$url = 'http://frankiejarrett.com/wp-content/uploads/2013/05/test-image.jpg';
$attachment_id = fjarrett_get_attachment_id_by_url( $url );
$path = ( $attachment_id ) ? get_attached_file( $attachment_id ) : null;
echo $path;
?>

For more information about what was used in this function, please see:
http://php.net/manual/en/function.explode.php
http://php.net/manual/en/function.parse-url.php
http://php.net/manual/en/function.str-ireplace.php
http://codex.wordpress.org/Function_Reference/home_url
http://codex.wordpress.org/Determining_Plugin_and_Content_Directories#Constants
http://codex.wordpress.org/Class_Reference/wpdb#SELECT_a_Column

Was this code helpful to you? Let me know in the comments!

Add prefixes to WordPress post types when a theme is activated

Recently, I had a real problem on my hands.

I had neglected to prefix the post type names in some of my themes, and as it turns out, so did another popular WordPress plugin. Long story short: this plugin became unusable when running my themes, and this did not make my users very happy.

It became clear that I needed to bust out some ninja moves to overcome this dilema.

The code below is the solution I drafted – maybe it will help you too. It’s a function that runs when the theme is in use, and rewrites the post type names in the database with any prefix you choose.

After the theme is activated the specified post types will be renamed to: fjarrett_acme, fjarrett_foo and fjarrett_bar.

Sadly, there is not yet a hook that will fire only when themes are activated/updated. The after_setup_theme action is a little misleading in that it fires when WordPress sets up the current theme, not when an admin activates and/or updates the current theme.

So, it’s basically firing with every load of WordPress when the theme is active. Someone first made a patch for this 3 years ago and it looks like it’s finally being revisited.

For that reason, this is by no means the most resource-friendly solution, but we are killing the script if the prefixed post type already exists – which requires an additional query – but this is crucial for two reasons:

  1. So we’re not attempting to update the database with every page load – after the original post types are given prefixes the database update will never run again.
  2. So other plugins/themes (like the one I was in conflict with) can be installed later, creating their blasphemous post type names, and we won’t attempt to rewrite them.

Hopefully this is helpful to you and your project in some way. If so, please tell me about it the comments!