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:


  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:


  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.


WordPress.org – Changing the site url

Why I’m considering removing blog comments

Many others before me have disabled their blog comments. In fact, a blog post by Seth Goden from 2006 still sticks in my mind and all the outcry it generated from around the web. The longer my blog has been around the worst the spam has gotten. In a way that kinda makes sense as my domain name gets shared via spammer databases and my growing number of blog post links get stored in search engine results.

Spam comments are awful. As of today, Askimet says it has blocked over 250,000 spam comments since March 2014. During the time it took to write this post I’ve already received 16 spam messages. For every single legitimate comment, I get 1,000 spam comments. Seriously. If managed improperly, spam comments can crash your blog if your hosting provider limits the size of your blog database.

This happened to me earlier in the year. Silly me, I thought that it would be impossible for me to go over my previous hosting providers pre-set 2 gigabyte database size limit any time soon. Most of my blog posts are text based and take up very little room. The entire size of my blog database was around 15 MBs. I didn’t even know there was a problem until I couldn’t create any more blog posts. Upon further examination I had received over 75,000 spam comments over a 30 day period and they were waiting patiently for deletion. I’m not exactly clear on why Askimet didn’t correctly report these, or automatically delete them within 15 days, or what exactly happened. One thing was clear: my comments table in the database was full of tens of thousands of spam comments. I thought I had set them for automatic deletion but apparently Askimet only auto-deletes the worst of the worst spam and everything else goes to the spam queue. Caveat Emptor.

I still think I see the value of comments in that everyone including me can benefit from the “shared” feedback including myself. But, the increasing amount of time and headaches spent dealing with spam is making me seriously reconsider.

Upgrade Anxiety – We all have it

As I type this I can see an icon indicating 10 plugins need to be upgraded on my blog. Most are minor upgrades with tweaks and fixes that don’t really affect me. Some, like the WP Super Cache update, are enough to give me nightmares of my blog having serious technical issues.

Oh wait…hah! Well, I actually did totally mess up my blog a couple years ago. I thought simply installing the WP Super Cache update would automatically preserve all of my settings. If you aren’t familiar with this WordPress plugin, it essentially provides a performance boost to your blog by having a gazillion caching-related knobs, bells and whistles that you can tune.

Yes, I did research the topic of upgrading beforehand. And at the time, deja vu, I found very little useful information other than people recommending you should upgrade. Caveat Emptor. I ended up paying a tech support person $175 to fix my mistake and my blog was totally messed up for about a week.

Okay, so now I make sure to backup/export all my WP Super Cache settings . Yet I still get the heebie-jeebies every single time I get its plug-in update notification.  A few friends offered some not-so-tongue-in-cheek suggestions of why don’t I just learn about all the different settings and just experiment. “You have the skill(z),” they told me. I couldn’t argue with that.

What it really comes down to is “how” I want to spend my time. Like most members of the Esri Developer Evangelist team, I’m totally slammed at work and the outdoors keep me busy after hours and on most weekends. I don’t really care to learn the nitty-gritty intricacies of WP Super Cache and it’s hundreds of configuration permutations, along with all the other stuff I have to learn to stay on top of the latest technologies, APIs, etc.

In hindsight, now I know the WP Super Cache website doesn’t have a single link or tab that explains the various settings and configuration options. There are ten steps listed that don’t even begin to cover what happens if you change something, or what are the pluses and minuses of doing one setting versus another.

Lessons Learned:

  • You don’t have to accept all upgrades whether it’s your laptop, smartphone app, etc. I’ve gotten really good at skipping some. Others, like Chrome, happen automatically and even though they also occasionally introduce new bugs.
  • Note to self: Always, always back up your software, databases and settings.
  • Some upgrades deserve more attention than others. WP Super Cache is one of those upgrades that deserves your full attention to details. Spend time on forums reading and asking questions before hitting the upgrade button.
  • Some upgrades simply aren’t worth it. I’ve dropped a number of plug-ins that mysteriously started gathering information from my blog such as AddThis. I was running a protocol analyzer at the time and I noticed strange http requests to a 3rd party URL. Not only were the synchronous http requests slowing down my website, but when I visited the 3rd party website the details of what they did were extremely vague.
  • The last lesson learned is actually a note to software vendors that may be reading this. Too many upgrade notifications per month is very annoying. Unless you find a fatal bug, one upgrade per month is about my limit.

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.

Going mobile with blogging

I’ve had several comments that my blog is not mobile web enabled and that I need to “put my money where my mouth is” and “practice what I preach”. Little did they know that I have in fact been investigating the various mobile web options and doing my homework. In fact, just in the last week I started experimenting on my live blog, which I will add is a scary thing to do and there have been some problems. So if you come back to the website and it looks like something has changed, it’s very possible it’s related to my ongoing modernizing efforts. And, puh-lease let me know if you see something is broken.

The approach(es). I’ve started with the approach of having two different themed websites: one theme for desktop and one theme for mobile web. Why? Because I’ve gotten quite a bit of feedback that some people like the utilitarian look and feel of the desktop theme. On that note, if you don’t like it now is the time to say something. I’m also looking at responsive (fluid) designs that use CSS3 media queries to hide and unhide content depending on the device and browser you are using. I’ll be tackling responsive designs next, and perhaps much sooner than expected if approach numero uno crashes and burns in a flaming, twisted mess.

Challenges. I can say one of my primary challenges is handling legacy content, for example short codes and existing plugins such as the ones that affect page load performance like Total Cache. If you are just starting out fresh then your life is significantly easier as you are starting with a clean slate. But I have almost 100 blog posts that need care and feeding and I don’t really want to be manually changing page content, if I don’t have to, so that the new website theme or plugin can have its’ way.

Fallback plan. At the moment I’m being very careful with taking a full backup of the website and the database, as well as copying specific files before playing with any plugins or theme changes. In the best case scenario I’d like to create a completely separate copy of the website to play with, however there is a good chance this isn’t going to happen unless I simply can’t get a theme or plug-in to work. Usually theme or plug-in changes are relatively painless, with the emphasis on ‘relatively’. Besides, I always recommend clients create a test copy of their website that’s not visible to the public. But, they are usually big(ger) organizations and have more resources. I may still do this if time permits, but my theory is if I really mess something up I can restore the site or database.

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.