Bugs

Bugs.

Computer bugs.

Most will credit Grace Hopper with establishing the use of the word “bug” to describe a problem with computers. A dead moth had been found in Harvard’s Mark II computer and Hopper used the term to identify the issue. Literally, a bug was found inside the computer.

However, the use of the word “bug” goes back over 140 years to Thomas Edison. He used that phrase when working on telegraph systems back in the late 1800s.

You can read all about it here.

I received an email earlier this week asking for some help on a website that was exhibiting very slow page loads, in excess of 2 minutes or more. Very few people have the patience to wait a couple of minutes for a page to load.

When I was teaching computer science many years ago, I remember telling my students that the process of debugging required three fundamental steps:

Step 1: identify the problem
Step 2: isolate the problem
Step 3: resolve the problem

The steps are not often easy as some bugs can be very difficult to track down. There is also the tendency to repeat the same approach to problem resolution. Expecting a different outcome from the same approach can lead to lengthy debugging sessions.

My first reaction, upon taking a closer look at the website, was to attribute the issue to outdated themes and plugins, this being a WordPress site.

I was careful to make a full backup of the site and the WordPress database, create a local instance on my desktop, and ensure that all components of the site were using current versions.

Although all good actions to take, that did not resolve the issue. I had yet to identify the problem.

Debugging on the web is fairly good relative to the old days when I was debugging C and Assembler code.

Browsers provide pretty good tools to step through a website and find the issue.

I am quite used to working through complex websites with the development view.

Bringing up my friend’s website allowed me to identify the problem almost immediately with the console trace. Upon loading certain areas of the site, the code failed when attempting to load a resource.

The reason? A bad link to an image file.

It happens with WordPress.

The code was unable to load the resource with the following snippet: <img src=”http://123.45.678.910/~userid/domain.com/wp-content/uploads/2018/08/image.jpg”…

It would eventually timeout and recover without loading the resource hence the lengthy page loads.

I had successfully completed step 1. I had identified the error. I then jumped right to step 3. After all, the problem was pretty obvious to me. And it was obvious. I just forgot to isolate it in the code.

These snippets with bad links were everywhere in the code. And the code was literally just a glob of unformatted text. Thousands of lines of dense code. Very hard to isolate in the WordPress admin panel as most of the pages were created using a visual composer plugin. Fixing the bad links in the WordPress admin panel is not the most fun way to spend your time. Tedious to go in and bring up isolated sections of the code.

After a few hours though, I had found them all and promoted the changes back up to the server.

I asked my friend to walk through the site to make sure I hadn’t missed anything. So far, so good.

Loading images from a hard-coded IP address instead of a domain name is not typically a good thing to do. Fortunately I did not have to go into the WordPress database to update link details. The issue was limited to bad links in the code itself.

I don’t know why it happened. Very few people have changelogs for their websites. I suspect someone was doing something on localhost and uploaded the code through FTP with client-side references. I was just happy to be able to resolve the problem in a timely fashion.

Not too bad for an old, retired CIO.