WordPress images missing after blog was moved

If you are reading this you probably just migrated your WordPress blog from one hosting provider to the other. If everything else on your blog has been restored and its working fine then congratulations since that was the hard part.

The good news is that restoring your images is fairly straightforward, and the even better news is you won’t have to manually modify all your image links.  This should give you some relief!

Here are the steps:

  1. Back up your database. Many hosting providers have this functionality built-in. If you are hosting your own blog it’s best to just go ahead get another fresh export of the database and copy it to your local machine again. This gives you the most up-to-date copy if something goes wrong in Step 6.
  2. Open your most recent blog post that has a broken image. Copy and paste the broken URL into a text editor. You should be able to figure out the broken link by clicking on the missing image’s empty holder. Example:

http://www.myoldsite.com/WordPress/wp-content/uploads/2014/12/test.png

  1. Fix this one image only using the WordPress blog post editor and save your changes. Then refresh your browser and make sure the image is now displaying correctly.

IMPORTANT NOTE: In the majority of cases this step will go just fine. However, if it doesn’t then there are a few potentially tricky reasons why your changes may not show up immediately. It may depend on how your blog cache is set up, for example if you are using TotalCache you may have to manually blow away your blogs cache(s). Also some hosting providers may take a few minutes to update your data in the cloud. And, lastly you may have to delete your browser cache depending on how the web server that is hosting your blog is configured. Sorry, sometimes there’s no easy answer here, but I believe it’s better for you to be aware.

  1. Now click on the new image and get its URL, then copy and paste the URL to your text editor. Note in my example there are some slight differences between the old and new  URLs. It’s these differences that we need to correct. Example of a new URL:

http://www.mynewsite.com/htdocs/WordPress/wp-content/uploads/2014/12/test.jpg

  1. Open up the database in a SQL editor window. One popular way to access the database is via phpMyAdmin.
  2. In the text editor create a SQL UPDATE command from the URLs mentioned above that you copied and pasted then run the UPDATE command. Here’s an example template of how your command might look. Be sure to modify just the URLs so they fit your unique Blog:

UPDATE wp_posts SET post_content = REPLACE(post_content,’www.myoldsite.com/htdocs’,’www.mynewsite.com’);

  1. Refresh your webpage and see if all the broken image links are restored.
  2. If for some reason your website crashes or the pages get messed up then you will need to restore the database and start over with Step 1 above. The most common reason for any problems happening is there was a mistake made when creating the SQL UPDATE statement.

Reference

WordPress.org – Changing the site url

Going mobile Part 2 – dealing with legacy content

This is part two in my “Going Mobile” series. As some you know I’m migrating my website to work on all smartphones and tablets. It’s been a really fun process, especially since at my day job I usually consult on how to do this. So, it’s been great to actually sink my teeth into my own full-blown project that also includes a content management system.

As I’ve mentioned before, I have almost 100 posts to manage through this transition along with a variety of plugins and hundreds of images. This site is not custom so upgrades and changes should be fairly routine.  What I mean is it’s a fairly run-of-the-mill WordPress installation so there isn’t anything really fancy or complicated about it. And, that’s the way I like it so it just runs itself without much maintenance or intervention.

So, I’m still in the preparatory phase of migrating over to mobile. There’s been a lot more things to deal with than the typical applications that I build. Here are some of the issues I’m working through now:  

Images not optimized for mobile. I have hundreds of images that I pasted into blog posts. Some of these are up to 400 pixels wide, which covers most of the screen for your average smartphone. Perhaps some good news is all of my images are PNG format, but they were intended for use on 1024×768 or greater monitor sizes. Now, if I change the size of these it could affect my default page formatting. I tried to avoid that type of problem in the very beginning in terms of how my images are placed on the page, but we’ll see. I’m still experimenting on what do, and in my estimation it all comes down to performance. If anyone has any recommendations let me know?

Web Server Permissions. My blog hosting provider is fairly strict on the server configurations and the mobile plug-in model requires server-side access. I basically traded some access for massively reliable uptime.  There have been some issues with the mobile plug-in and how it works with various pieces of WordPress, PHP and the web server itself. If you work for an organization with full admin access to your web server then this shouldn’t be much of an issue.

Blog post length. I have some long blog posts that require a bit of scrolling. I don’t know if there is a right or wrong answer on the appropriate length of a non-paginated blog post. Personally, I hate paginated websites and as a default I expect to get the full article. I read a few blogs already on my phone and while I don’t mind scrolling down I’ll have to see what kind of feedback I get from visitors and regular readers.

Cross-browser testing. With my current blog, I’ve never ever had to worry about cross-browser testing. WordPress just works, period. I’ve occasionally received browser-related complaints. However, after some investigation the majority of the complaints were spam emails try to trick you into clicking on a hostile link. Once I get everything up and running I’ve created a simple test sheet with various check-off items to make sure I’m (mostly) comfortable and can sleep at night knowing I didn’t just hose things up dramatically.

Plug-in compatibility with WordPress upgrades. This is a major concern. I like building my own software because I can adapt it to any underlying changes. With a plug-in you are at the mercy of the plug-in vendor and your content management system. My fallback plan for this is I can always disable the plug-in. For now while I’m in the experimenting phase, my blog foundation will remain fixed and designed for 1024×768 content. Ah yes good old 1024×768. So, if I do pull the plug on the plug-in (no pun intended) then in theory everything should revert back to my default theme until I can figure out a fix or move on to a more responsive design approach.

Maximum WordPress Spam Prevention: Part 2

Anyone who has a public facing blog knows about being bombarded by spam. Recently I got so annoyed I started locking down blog comments after thirty days. After a month or so I realized this was counter productive. Readers could no longer participate, ask questions, etc. so I started searching for a better way to handle my anti-spam measures.

After doing a bunch of research I landed on Askimet. Note, I am not being sponsored by Askimet, I truly did this research on my own. I can say so far the results have been awesome. I’ve been able to turn all blog comments back on, and it’s very rare for a spam comment to sneak through. 99.9999% of the time when that happens it seems that Askimet has already killed the spam by the time I get around to viewing the WordPress spam queue.

Since turning Askimet on I haven’t had to personally deal with 462 spam comments. Yay! In the screenshot below, the 228 spam comments number represents a partial snapshot of the spam that I had to manually delete prior to Askimet.

Maximum Anti-spam Measures for WordPress

On my blog I’ve had to take what I consider maximum, or perhaps even extreme, measures to minimize spam. I use captcha’s, which I don’t particularly like, as well as mandatory approval for comments along with shutting off comments after 30 days. Oh, and I’ve also commented out the code that allows for trackbacks and pingbacks.  It was the combination of these measures that finally gave me some peace-of-mind.

Back during the month when I finally implemented all of these anti-spam methods I had received over 400 spam messages via various methods. It was filling up my mail box and getting really annoying. Mostly it was the time wasted while glancing at each message to weed out legitimate comments from junk before deleting it. Now I’m down to around six or so spam comment posts per month, and while this is still annoying is a much more manageable number.

I’ve gradually accepted that I won’t be able to completely eliminate spam (argh!). And, there are several downsides to this heavy handed approach. Now, every time I upgrade to a new version of WordPress I have to re-comment out the trackbacks and pingbacks PHP code. If I don’t, I start getting spam again within 24 hours. Also, if someone wants to post a legitimate comment after 30 days they won’t be able to.

Minor Code Change – Bye Bye WordPress Trackback Spam

I’ve been getting a bit frustrated with thirty or more trackback/pingback spam emails per day from my blog. I’ve been trying to ignore it for about a month, but my inbox keeps filling up. So, I did some research and, surprisingly, most of the anti-spam WordPress blog posts are from five to six years ago. I’m currently using WordPress 3.2.1.

Some of the fixes/hacks crashed my blog faster than you can blink an eye. Others, such as turning off trackbacks/pingsbacks in the WordPress settings did nothing to stop the waterfall o’ spam. Simply put: most of the old hacks don’t work on the latest version of the WordPress. One fix was to install the Askimet plug-in, but that required registering for a key and I didn’t feel like doing that.

So, I decided to actually look at the WordPress code and create my own home-made hack just to see if it might work. What I’ve done is rather brute force.

Step 1. Locate the php file responsible for trackbacks. On my system it’s under /htdocs/WordPress/wp-trackback.php.

Step 2. [Update: 11/18/2011] Comment out the following two lines of code. Then save your work and make sure your blog still runs. These lines of code are the one that writes the trackback to the database. In theory, if I stop that from happening then I won’t be annoyed by spambots for at least a little while.

 //wp_new_comment($commentdata);
 //do_action('trackback_post', $wpdb->insert_id);

So, now that’s done I’m going to sit back and wait. I’ll update the post if my “experiment” is successful. Or, if I have to dig further into the WordPress code.

[Update: 11/18/2011] With the additional line commented out all trackbacks are now ignored and they cannot be written to the database. Sweet!