If Plan A Fails – A Lesson Learnt The Hard Way

You know when you have one of those days when technology just does not want to work with you?  I had one of those days this week and I thought I would share it with you.  Even doing this stuff day in day out does not make me immune to brain farts or technology gremlins.

I had created a new WordPress website for a client on a subdomain of My Local Business Online.  When the client was happy, I backed up the site and got ready to transfer it over and replace their current WordPress site.

The site had the Duplicator plugin already installed and I had successfully used this to copy their old site over to the test server. I decided to use the same plugin to copy everything back.  It should have been simple…

And, I should have known better!

Plan A

Let me fly back in time a few weeks.  This job originally started out as a WordPress Service and MOT.  The client needed updates to some pages.  On logging in, I discovered WordPress itself had not been updated in over 2 years.

To make matters even more fun and challenging, the original site (even though it was built on WordPress) didn’t have any pages that were editable the normal way.  The original developer had created page templates within the basic WordPress theme.  Basically, to edit the pages you would need to go back into the original WordPress files to make changes.

Even worse, the original theme needed updating (and is so old anyway, it’s no longer in standard use – it pre-dates TwentyTen etc).  On updating the theme, all templates and other changes they had made to the theme was lost. 

Thankfully, this was on the subdomain test site, so no damage done!

It did mean that there was no safe way to upgrade WordPress and the theme without creating a child theme first and starting again.  I’m not a coder, to sub-contract this out would have been more expensive than putting on a new theme and recreating the pages.  It isn’t a big site, just 5 pages, but every page was a template created inside the WordPress theme.

Plan B

I agreed with the client to put on an up-to-date responsive theme, create pages how they are supposed to be created and move the whole lot back to the original server.

Simple

Until I came to move it back.  As usual, I do this type of thing well out of normal UK hours to minimise any disruption.  At 11pm I sat down with my coffee and started checking the backup and moving files over to the server.

I used the original Duplicator plugin, which requires you to remove the wp-config file and set up a new database.  Nothing unusual with that for a free plugin.

Duplicator couldn’t unpack the backup file it created.  I had checked it, but just in case it was a bad file, I re-backed up using Duplicator and uploaded the new backup.  Again, it wouldn’t unpack and gave a bad file error.

Just to make sure I wasn’t going mad, I used Duplicator to clone the site onto another test site.  It worked perfectly!

Plan C

At this point, it was getting late and I decided to upload the original wp-config file via the file manager and look at the site again in the morning.  The file appeared to upload ok.  File manager gave the uploaded complete message.

On refreshing the site, there was an error in the wp-blog-header file and the site wouldn’t load. 

Plan D

You would think I would realise this error was related to the wp-config file and not the wp-blog-header file.  It was late, 2am.  So I replaced the blog-header file from the original backup via file manager.

Guess the result?

The site wouldn’t load!

It was at this point my brain kicked into gear.  I realised I had far surpassed the size limit allowed by the host.  Uploading one backup file had passed the limit, no wonder it wouldn’t unpack.  I’d uploaded two backups and two individual files.

The wp-config is the file that tells WordPress where the database is.  It appeared to be on the server but actually, the file was 0mb in size.  The file was empty!  No wonder the site wouldn’t load.

Plan E

I dug out my ftp program and planned to upload the files individually via ftp.  A pain, it takes longer.  WordPress has over 5000 files.

I added a new ftp user via cPanel and tried to connect.

You guessed it – I couldn’t connect.

Teeth gnashing eschewed

Then I noticed that I needed to whitelist my IP to connect with ftp. 

I tried, I really did.  I kept getting the error message my IP address did not exist. 

By uploading one medium sized file through the file manager, I had overloaded the server.  I knew my client used their “IT guys” reseller hosting but I had no idea who it was.  It was gone 3am anyway and I doubt they would appreciate a call!

There was no option but to email the client asking them to call me a.s.a.p. and get then get some sleep.  Not that I slept much, leaving a live site pointing to an error message kept me awake the rest of the night.

Plan F

I contacted the “IT guys”.  They were really helpful, whitelisted my IP and upped the size allowance. 

I wasn’t about to mess around this time. I used my preferred backup software (The Backup Creator), created a matching database and uploaded the test site backup.  Job done in a few minutes!

Learning the hard way

My mistake?

Assuming that I could do what I wanted to do. 

Assuming just because on every single WordPress site I have installed or recovered using cPanel (and there have been quite a few!) and the disc space provided by the hosts has allowed me to do it direct in file manager, I could do it again.

Well we know what assume does!

In this case, the hosting package did not provide enough disc space to even manually install WordPress via cPanel, let alone actual content and plugins too.

There is always a silver lining

I have another site on the same host to update.  I won’t be making the same mistake!

Additionally, all the messing around highlighted that even with working backups we would not have been easily able to restore the site should a complete site failure happen.

Over to you…

If you have read this far, well done and thanks for staying with me!  What lessons have you learnt the hard way?