This drove me batty for awhile. All my recent images in WordPress could be “smushed” by WP Smush it, but everything before 2009 had a bulk error message. If you’re here you’ve probably already seen it, but just to make sure we’re all on the same page, here’s what it might look like:

Essentially, it says Could not find /home/yaddayadda/public_html/etc. And in this case if you look at the location, it actually flows through twice – you’ll see the double slash // after the first “uploads” and it starts again. I’d done a little searching for a quick fix but wasn’t having any luck, so it was time to start digging!

The cause (for me, anyway)

Normally, image locations are stored in the WordPress database with their relative path. This means something like 2006/04/image.png. When it comes time to find the image, WordPress looks at your setup to see where your images are stored (generally i ), and starts putting everything together to get the final full path. It’s great because it makes things more portable.

Unfortunately back when I created the WordPress site in 2006, for whatever reason, images that I uploaded were being stored in the database with their absolute path. For those who don’t know the lingo, absolute in this case means something like /home/server_account/public_html/i/2006/04/image.png. As you might guess, this can cause a problem if you ever move your upload folder (or the WordPress installation) to another location on the server (or onto another server with a different account name). When I transferred to another host in 2008, evidently I must have made a change that fixed things to use a relative path, which is why everything uploaded since 2009 was smushing fine for me.

In any case, while WordPress itself can survive with an absolute path (as long as it’s correct), the absolute path causes a problem for WP Smush.it. From what I can tell, it will jam the location of your uploads folder in front of the path no matter what. So if your images were being stored in the database with an absolute path, you end up in a bit of a pickle.

Ok, enough yammering. How to fix?!

Just to forewarn you, part of this process involves manually editing your WordPress database. So if you’re not comfortable doing that, you might want to keep looking and hope somebody’s come up with a more elegant solution. And even if you are comfortable, *****back up first***** just in case!!!

Now I’m going to make an assumption here – remember that I said my recent images were working fine (being smushed properly). I’m assuming the same holds true for you and that if you were to upload a new image right now, it would smush fine. If that’s *not* the case, you’ll want to address that problem first.

Step 1 (after you’ve backed up) – editing the database

A) the safer (but longer) way – manual editing

I used phpMyAdmin, but there are probably some WordPress database plugins you can use if you don’t have access to phpMyAdmin.

1) Open your wordpress database and select the wp_postmeta table
2) Locate the _wp_attached_file entries you’re having a problem smushing, and click “Edit“. (don’t bother editing the _wp_attachment_metadata entries – making changes there doesn’t work and thus we’ll get WordPress to regenerate them later).

click image below for larger view

notice that the meta_value of the first 2 (labelled GOOD) is 2006/03/sitemaps1.gif which is a relative path. On the other hand, the ones labelled BAD have a path that starts with /home/ which is an absolute path which we don’t want.

TIP: If you looked at the image, you probably noticed… this is a bit of a mess. One thing that can be helpful is to have another browser (or tab) open with your WordPress Media Library, and look for the ID of the URL when you mouse over each of the problematic images (as long as your browser shows the status bar at the bottom, you should see it there). You can also mouse over the “Re-smush” button – it will show the same ID number. Match this up to the number in the “post_id” column in the database table to match up the images to the database entry.

3) Once in the editing page, trim down the file location/path. Click the images below for a before and after.

 
If you have WordPress set up to organize image uploads by year & month, chances are your final result will look identical to the 2nd image, deleting everything up to and including i/ and leaving the remainder.
Remember, you do not want a leading slash.

4) Once you hit “Go”, you should be looking at the table again. And the entry you just edited should look correct.

TIP: Before editing the next one (and the next, and the next), you should probably continue to the next step below just to make sure nothing goes haywire. Besides, it would be a shame to edit a hundred of these only to find out your stuff still doesn’t smush at the very end for some reason. Just worry about this one image for now until you know everything is A-OK.

B) the quick and dangerous way

Instead of manually editing all those rows, if you have access to phpMyAdmin and don’t feel like manually editing dozens (possibly hundreds of lines depending on how many images you have), it’s possible to do a MySQL query to issue a big search & replace.

Note that I strongly recommend you edit at least 1 row manually first – if nothing else, it will give you an understanding as to what you’re doing. Oh, and if you haven’t yet for some reason, make double sure you’ve backed up. One SQL query gone wrong can trash your site in a heartbeat.

The preliminary: 

If you remember our manual method above, we’re essentially changing things like:

/home/username/public_html/i/2006/08/image.jpg

 to:

2006/08/image.jpg

That /home/username/public_html/i/ is basically being deleted over and over again, once for each image. Instead of doing it manually, to save some time we can tell MySQL to just run through the entire wp_postmeta table and delete every instance of /home/username/public_html/i/ that it finds. It’s a little dangerous because if for some reason WordPress or another plugin actually put that line there for something else and needs it there…. well it’ll be gone. I did a quick glance and didn’t notice anything that should be problematic, but for all I know maybe in the next version of WordPress they’ll have something new there that this will destroy. Did I mention you should back up first?

Let’s get started.

1) Follow the “manual” instructions above up until this point:

You’ll see I modified the instructions slightly. You’re going to select this and copy it to the clipboard with CTRL-C, or CMD-C on the Mac. Or right-click copy. Or…. well let’s just say if you don’t even know how to copy, I’m very shocked (yet extremely impressed) that you’re comfortable editing a database.

Now paste that line in a text document somewhere. We have to start putting together the SQL query.

The format we’re going to use is as follows:

UPDATE `table_name` SET `field_name` = replace(same_field_name, 'unwanted_text', 'wanted_text')

It may be best just to copy that entire line to a text file rather than type it out. There are 2 different types of quotes used in the above line ` ‘ and it’s easy to accidentally use the wrong one. We do have to change those colored items to the proper values, so here’s what we will be changing them to.

table_name is going to be wp_postmeta (if you have a prefix other than “wp_“, make sure you use your prefix instead)
field_name is going to be meta_value (you can see in the above image that was the name of the field we were editing)
same_field_name is going to be meta_value also
unwanted_text is the line we copied with CTRL-C before
wanted_text will be deleted, leaving just the 2 single-quotes.

Go ahead and make those changes now. With the changes in place, you should now have something that *resembles* this:

UPDATE `wp_postmeta` SET `meta_value` = replace(meta_value, '/home/username/public_html/i/', '')

Chances are that with a standard installation, yours looks identical except for the green line (unless your webhost literally gave you “username” as a username and you managed to have the exact same path issue as me). Remember, you’re using the line you did a CTRL-C with.

So now to put it in:

1) With your database selected, choose the SQL tab from the top.
2) Paste your UPDATE line in (if there’s default text, just copy over it)
3) Hit “Go”

If you’re successful, it will bring you to a next page that tells you the # number of rows that were changed. You may want to browse to the wp_postmeta table and take a quick look just to be sure the change took place correctly. If something rather horrible happened instead (or something really hard to fix… like if you missed a slash and deleted upload instead of upload/ ), make sure you have that backed up database ready and restore it.

Step 2 – Out of the database editor, and into a plugin.

Unfortunately, just editing the database isn’t enough. We need WordPress to regenerate the attachment metadata (basically the rows in the database table that we didn’t edit).

The easiest way I’ve found to do this is via a plugin called Regenerate Thumbnails. To be honest it does more than we need it to, but I was having trouble finding a plugin who’s only job was to regenerate metadata. I’ll let you guess at the purpose of Regenerate Thumbnails, but here’s what works well for us:

1) It installs easy (you can install it from within WordPress), and no configuration to muck with.
2) If you just want to regenerate thumbnails (and metadata) for specific images, you can, and it’s easy.
3) If you want to regenerate thumbnails (and metadata) for everything, you could do that too, and it’s easy.

Of course, there are a couple possible downsides… the plugin is going to re-create thumbnails based on what the current values are in Settings/Media (for thumbnail, small, medium, and large). If you’ve tweaked the image size settings there a few times in the past, just use your imagination and you can see the potential for some unintended consequences. Also, if a large number of your images were un-smushable and you’re planning to use this plugin to regenerate for *all* images at once, your server load might skyrocket until it’s complete. You may want to do it early morning to minimize the impact on web traffic. Be very cautious about using this if on  shared server, particularly if you have thousands of images.

You may want to regenerate one image at a time to be on the safe side. Keep in mind that there are probably a number of other plugins that would work if you’d prefer something else – Regenerate Thumbnails was simply the first one I came across that looked like it would meet my needs.

I strongly suggest backing up your images before continuing just in case… You can do a full website backup easily through cPanel if your host uses it. Otherwise at the very least, tar or zip the contents of your uploads folder.

Ok, so assuming you installed it and activated the plugin, here are the next steps:

1) Pop into the Media Library, find the image you edited in the database, and click Regenerate Thumbnails.

2) Assuming it completes without error (it should work if the database editing went fine), hit Re-Smush.

The nasty “Could not find” message should now disappear, and……

Aaaand….. VOILA!

If your single-image trial worked, head back up to part 1 and start pounding through the images (check your posts periodically to make sure images are still showing with no ill side-effects).

Wrapping things up

Ok, that was a lot of work. But hopefully by the end all your images can be easily smushed. Take a peak at some of your posts just to make sure everything still looks as it should, and keep those backups handy just in case you run into a problem a few days later.

If you’ve gone through the process and have any tips or stories to share (hopefully good success stories, but horror stories will do too), feel free to do so in the comment section below!