Migration complete… but where are the images?

Trello board tracking the migration of my websites
Trello board tracking the migration of my websites

For much of the last two weeks I’ve focussed on two things:

  1. Redesign my website (garethjmsaunders.co.uk)
  2. Migrate that site, this blog, my SEC digital calendar site, and the NYCGB alumni website to a new web host (SiteGround).

I’ve managed to complete the project three days early… well, kind of.

WordPress… we have a problem

One unforeseen snag has been to do with the media (images, PDFs, zip files, etc.) on this blog.

I’ve been using WordPress since version 0.7 in 2003. During that time I’ve been uploading image after image, and as WordPress changed the way that it stored images I’ve experimented with different ways of organising it—even simply uploading the images to my server via FTP. I must have tried about four or five different arrangements.

For the most part, though, I’ve been uploading files directly into /wp-content. Occasionally I’d switch on the “organise my uploads into month- and year-based folders” option.

In short the organisation of media on this blog has been a mess, and I’ve always shied away from addressing it because… well, it worked.

When I came to consider migrating this blog from Heart Internet to SiteGround I did think about the media: would it be a problem if I simply transferred everything over as is and sort it out there.

I was a fairly tight schedule (it had to be completed by 20 January so that my Heart Internet hosting account wasn’t renewed) and I reckoned that since it worked fine at Heart Internet then it should work at SiteGround.

I was wrong.

cPanel and the mystery of the 1,998 files

SiteGround uses cPanel. As Wikipedia explains, “cPanel is a Linux-based web hosting control panel that provides a graphical interface and automation tools designed to simplify the process of hosting a web site.”

cPanel uses Pure-FTPd, a free (BSD licence) FTP server which by default shows up to 2,000 files in each folder. I found that out after the event tucked away in the cPanel documentation.

I had 3,688 files plus 10 directories in my /wp-content folder and I couldn’t figure out why it would only display 1,998 files and the previously  visible directories, such as /plugins and /themes had disappeared.


I am manually working my way through the media library. Uploading files into the appropriate /wp-content/uploads/<year>/<month> directories and updating the database to tell WordPress where the files are.

For those files that were uploaded before there was such a good media library I’m using the Add From Server plugin to quickly import media into the WordPress uploads manager.

This is going to take a while, so please bear with me.


Monday 19 January 2015

I’m making good progress already. I’ve fixed 360/700 images in the media library. That’s 51%, just over the halfway mark.

I’m finding it strangely satisfying getting this sorted out. A bit of website gardening.

Problem connecting my Google Nexus 4 to Windows 8.1

My Google Nexus 4 has been playing up lately: taking ages to connect to WiFi and burning up battery extra quickly. Time for another factory reset, I thought, so plugged it into my PC to backup my ebooks, music files and photographs only to discover that it no longer showed up in Windows Explorer.

It turns out that a recent Windows 8.1 update has prevented many Android users from connecting their devices.

I found the solution on this post on Stack Overflow: Windows 8.1 Device Manager now showing ACER Device rather than Android Device for Google Nexus 7.

As far as I recall, this is roughly what I did:

  1. In Windows Device Manager click on View > Show hidden devices.
  2. Locate the ACER Composite ADB Interface uninstall all instances of it.
  3. Reboot PC.
  4. Plug in Android phone.
  5. Return to Device Manager and open ‘ACER Composite ADB Interface and select ‘Update Driver…‘.
  6. Select ‘Browse my computer for driver software‘.
  7. Select ‘Let me pick from a list of device drivers on my computer‘.
  8. From the list select ‘MTP USB Device‘.
  9. Click Next.
  10. Unplug Android phone.
  11. Reboot PC.
  12. Plug in Android phone.
  13. Windows 8.1 showed the phone in Windows Explorer.
Nexus 4 listed as a device in Windows Explorer.
Nexus 4 listed as a device in Windows Explorer.

For some reason I had to do this twice. It may have been because I had ‘USB Debugging’ activated in Settings > Developer Options, and I unticked it the second time.

Anyway, I can now connect my Nexus 4 to my PC. Panic over.


BT Broadband finally fixed… maybe BT does care after all

BT speed test results: 16.8 Mb connection to exchange

It has taken me a couple of weeks to write this post. I didn’t want to be overly hasty; I didn’t want to make claims that I couldn’t substantiate. But our broadband connection, which has been a bit flaky since early December, and downright annoying since late January has finally been fixed, after five visits from BT Openreach engineers (one in December, two in February, two in March).

The story so far…

During that time we had the following work done:

  • BT Home Hub 3 replaced for a newer Home Hub 4.
  • Line faults (over 3,000 of them, apparently) cleared from the networking equipment in our street.
  • Master socket changed.
  • Master socket moved from hallway to living room.
  • Changed which pair of wires connects our master socket to the exchange.
  • Powerline adapter changed.

None of this fixed the issue of our broadband connection dropping randomly throughout the day; at most over 100 times a day.

Engineer #5

When the fifth BT Openreach engineer rolled up my spirits lifted a little. This chap—Andy Smith, I think his name is—had visited us about a year ago to resolve a similar issue and he had gone beyond the call of duty to fix our connection by disconnecting all the unused extensions around the house which resulted in a 2Mb increase in download speed.

Like any good physician, he listened to my tale of woe before getting to work checking connections, running line speeds, investigating the BT box in the street. But he returned looking quite glum, reporting that all the tests returned fine: there is definitely not a line fault BUT he could see from his results that there was a problem, he just couldn’t put his finger on it. There was nothing else he could do.

PPP LCP Send Termination Request [User request]

I ran upstairs to fetch a piece of paper that I wanted him to see. It was a print out of the error log the last time it went down. I had noticed that preceding each drop out the error log reported “PPP LCP Send Termination Request [User request]”.

He read the error log and stroked his chin (metaphorically if not literally). “Hmmm…. PPP? Point-to-point protocol. That’s to do with connection not sync speed.”

Then he looked up at me. “That’s all a bit beyond me, to be honest. I don’t understand what it all means…”

My heart sank.

“… but I do know someone who does!” He got out his mobile phone, called a colleague, and then spoke gobbledegook for ten minutes before calling me down the stairs again.

The plan was to “move [me] to new broadband equipment at the exchange”. The engineer at the other end of the phone had already done it from his end, but Andy needed to drive to the exchange and physically swap our network cable from one piece of kit to another. It would take about 10 minutes.


And that was it. Fixed! We had a steady, solid, fast connection for over 7 days before it performed another reboot, but it looks like this was just to re-sync the speed; it did it again this afternoon.

And as for @BTCare…

A few weeks ago, in the midst of our most frustrating experience of BT broadband I wrote a very disappointed blog post. I’m sorry I felt that I had to write that post, because as I had said before and as I have waxed lyrical to many people over the years on the whole I’ve found @BTCare to be a world-class customer service experience.

It did the job, however. Twenty minutes after posting that mild diatribe, I took a call from Niall at BTCare. “How are you today?” he asked.

“I’m really disappointed,” I said, quite honestly.

Niall was very apologetic about not getting in touch when he said he would. He never missed another call again. He called each time he said he would, and he faithfully kept up to date with the progress of my support incident.

In short, Niall actually did restore my confidence in BTCare—it just goes to show the difference that one person can make on behalf of the company they represent in changing attitudes. By the end of it I certainly felt that Niall from BT cared, and Andy Smith from BT Openreach cared, even if BT itself was still maybe a little ambivalent about me, so long as I kept paying my monthly bills.

Which reminds me, they offered me a refund on my broadband connection back to the date in January that this portion of the incident was first reported.

A very enthusiastic and heartfelt thank you to Niall at BTCare, and Andy Smith (?) at BT Openreach.

Broadband woes /continued

BT Openreach van parked outside our house on Tuesday 18 February
BT Openreach van parked outside our house on Tuesday 18 February

Having had a minor battle to get @BTCare phone us back last week they finally, and I must say apologetically and humbly, arranged for a BT Openreach engineer to visit the house.

He turned up on Wednesday morning (18 February). A lovely chap, cheerful and engaging. What I really respected about him was that he listened to my tales of woe regarding broadband and crackly-line telephone calls before plugging in his equipment and running various tests.

The tests completed successfully: no faults. Hmm… Then he plugged in his phone to our extension and something grabbed his attention.

“Well… something just changed when I plugged in the phone,” he said. He showed me his meter, the display had suddenly leapt from 0 faults to over 1,500.

He moved operations from our living room (where the home hub is plugged into our solitary extension socket) to the master socket near the front door. His meter climbed to over 3,500 faults.

At this point Isaac returned home from playgroup with a friend and I attended to their lunch in the kitchen while the Openreach engineer donned a hi-vis jacket and poked around beneath a manhole in the street to clear the faults.

He suggested that this may solve the issue, if not then we may be looking at an issue with repetitive electrical impulse noise (Rein) when interference from an external power source interferes with the broadband signal.

Since his visit three days ago our connection has dropped out 29 times so far. There seems to be no obvious pattern to it. These are the values recorded in the router logs after the engineer left:

Tuesday 18 February

  • 16:30:59, 18 Feb. (DSL is down after 229 minutes)

Wednesday 19 February

  1. 15:39:18, 19 Feb. (DSL is down after 1387 minutes)
  2. 16:20:14, 19 Feb. (DSL is down after 40 minutes)
  3. 16:21:37, 19 Feb. (DSL is down after 0 minutes)
  4. 17:16:47, 19 Feb. (DSL is down after 54 minutes)
  5. 17:37:38, 19 Feb. (DSL is down after 10 minutes)
  6. 21:00:08, 19 Feb. (DSL is down after 201 minutes)

Thursday 20 February

  1. 02:12:53, 20 Feb. (DSL is down after 311 minutes)
  2. 02:13:48, 20 Feb. (DSL is down after 0 minutes)
  3. 05:56:33, 20 Feb. (DSL is down after 222 minutes)
  4. 10:11:48, 20 Feb. (DSL is down after 254 minutes)
  5. 13:38:08, 20 Feb. (DSL is down after 205 minutes)
  6. 14:22:27, 20 Feb. (DSL is down after 43 minutes)
  7. 16:56:52, 20 Feb (DSL is down after 153 minutes)
  8. 17:05:25, 20 Feb (DSL is down after 7 minutes)
  9. 18:00:14, 20 Feb. (DSL is down after 53 minutes)
  10. 18:53:33, 20 Feb. (DSL is down after 52 minutes)
  11. 18:54:26, 20 Feb. (DSL is down after 0 minutes)
  12. 21:48:25, 20 Feb. (DSL is down after 173 minutes)
  13. 22:32:53, 20 Feb. (DSL is down after 43 minutes)

Friday 21 February

  1. 10:01:15, 21 Feb. (DSL is down after 687 minutes)
  2. 11:03:35, 21 Feb. (DSL is down after 61 minutes)
  3. 11:07:53, 21 Feb. (DSL is down after 3 minutes)
  4. 21:13:15, 21 Feb. (DSL is down after 604 minutes)
  5. 21:14:14, 21 Feb. (DSL is down after 0 minutes)
  6. 21:19:43, 21 Feb (DSL is down after 4 minutes)
  7. 21:20:37, 21 Feb. (DSL is down after 0 minutes)
  8. 21:36:52, 21 Feb. (DSL is down after 15 minutes)
  9. 21:37:47, 21 Feb. (DSL is down after 0 minutes)

I’ve started recording the line rate speeds (mostly around 888 Kbps upstream, 9720 Kbps downstream, which is significantly less than we’re used to) and noise margins too (12.00 dB upstream/10.60 dB downstream on Thursday dropping to 7.60 dB upstream/8.90 dB downstream today) in case these are important factors.

We also have an electrician visiting the house tomorrow morning to inspect the wiring to try to rule out that as possible cause of Rein.