How to run more efficient meetings

I used to think that I didn’t enjoy client meetings. I always felt that they were a waste of time and that I could achieve far more by simply communicating with clients over email. I included phone calls in my definition of meetings too by the way. I felt like email was a much more effective way of communicating as they contained everything that needed to be said and could be referred back to at any point in the future. But let’s be honest, no one reads emails. And just because you have a world-class folder structure in your Gmail doesn’t mean you client does. Email is also terrible for conveying nuance and as for brain-storming ideas? Forget it. So I would begrudgingly go along to meetings but always feel they were an inefficient drain on my time. And they were, because I didn’t know how to plan or structure them properly. But over time I learned how to run more efficient meetings.

It’s no real surprise I was bad at meetings as I was never taught how to run them, but I’m ashamed to say it took rather longer than it should have to start making meetings work for me. I think this was partly because I read something antagonistic about meetings being a waste of time. Anyway, if you’re crap at running meetings like I was I hope the following advice may be of some use to you.

Before the meeting

  • Decide on the finish time of the meeting as well as the start time
  • Decide on a few clear things (ideally less than five) you want to achieve in the meeting
  • Send a clear agenda to everyone who will be in attendance at least one day before the meeting
  • Ask for additions to the agenda when you send it. Resend the agenda to everyone if there are updates
  • State who will be leading the meeting when you send the agenda

At the meeting

  • Have a timekeeper who can move things along if needed. This will often be the meeting leader but not always.
  • Only write down the most important points. Record the meeting audio rather than trying to take copious hand-written notes. As a courtesy ask if anyone minds you doing this (they won’t).
  • End the meeting by agreeing on what the next steps for the project are and who is responsible.

After the meeting

  • Write up conclusions, questions that arose and next steps and email this to everyone who attended the meeting. Offer to send the meeting audio to anyone if they want it (they won’t).

So now you’ve leaned how to run more efficient meetings you’ll be amazed by how useful they can be. Good ideas will come up, questions will be answered, problems will be avoided and you will look like you really know what you’re doing. As long as there is a clear purpose and you stay on track meetings can be very worthwhile indeed.


Move WordPress from localhost to server without using plugins

If you develop your WordPress websites on a local machine you might be viewing at a URL like localhost:8888/yourdevsite/ which is fine until you get to the point you need to launch the website or move it online for a client to take a look. I’m going to show you how to move WordPress from localhost to server without using plugins.

The problem you’ll face if you copy the local database over to your server all of your internal links will be broken as they’ll all point to localhost. One solution is to create a completely fresh WordPress install on the new server and copy over just the theme and plugin files before re-inputting any content. This approach is OK for very small sites but is a huge pain if you’ve spent any time at all on this already. There’s also the chance that you’ll miss something. The other option is to update the URLs wherever they appear in your WordPress database.

There are a few different ways you can update the database. As with most WordPress tasks I prefer to do things without the use of a third-party plugin, especially if it something pretty easy like this. Ignoring the plugin route, you can either run an SQL command on your database or export and modify the database. I prefer the export option as it leaves the original database intact.

First, have you removed any insecure passwords?

Before we start, let’s take a moment to think about security. One mistake I’ve seen people make when moving a dev site to a live server is to leave a highly insecure admin account in place. I recommend using strong, hard-to-guess usernames and strong passwords even while in your local development environment. If you have an a user account called ‘admin’ with a password of ‘password’ then please make sure to change it while still in you local environment and before you begin this process.

Updating your database URLS in a text editor

Export your local database to a file

If you’re using PHPMyAdmin or MySQLWorkbench locally you can quickly export the contents of your database to a file which can be opened in a text editor like Sublime Text, BBEdit, TextWrangler or anything else.

In PHPMyAdmin just click the Export tab, choose the Quick option under Export Method, make sure the Format is set to SQL and then click Go. You’ll be asked to choose a location to save the file.

In MySQLWorkbench choose the Data Export option from the Server menu, and choose the database to export in the Tables to Export window. Lower down the screen you can choose al location to save the file where it says Export to Self-Contained File. Now just click Start Export and save the file.

Use a text editor to find and replace the URLs

Open your exported file in your text editor of choice. I use BBEdit for this. Now you can simply do a find and replace changing http://localhost:8888/yourdevsite/ to

Once that’s done save the file.

Import the updated file on your live server

Now move over to your live server and create the database through your hosting control panel, MySQLWorkbench or Terminal. Make a note of the database name and password for later.

Now you need to import the database file you modified and saved in the previous step. In PHPMyAdmin you do this from the Import tab. In MySQLWorkbench it’s the Data Import option, which you’ll find in the Server menu again.

Upload your WordPress files

You will also need to move your site files of course as we’ve only ported across the database so far. I like to do this with SSH but if you need to use FTP that’ll work too. Just copy your complete local site including all WordPress files, plugins, theme files and uploads to wherever they’re going to live on the live server.

Update your WordPress configuration file

The last part of the puzzle is allowing WordPress to connect to the database. To do this edit your wp-config.php file to point to the new database name and password. After you’ve done that you should be able to view the site in its new home including all your previously entered content.


Moz 804 SSL Crawl Error

I’ve been tracking our company website in a Moz Pro campaign for a few months and found it quite useful. Everything was going great until I moved the site to Amazon’s CloudFront CDN. Every week Moz emails me with a list of any potential SEO issues to fix on the site and the first of these reports that came through after the move contained a big one, an 804 SSL Crawl Error to be precise.

Error Code 804: HTTPS (SSL) Error Encountered

We were unable to access your homepage, which prevented us from crawling the rest of your site. It is likely that other browsers as well as search engines may encounter this problem and abort their sessions. This could be a temporary outage, but we recommend making sure your network and server are working correctly.

This was obviously not good news. My first thought was that I must’ve made a mistake when setting things up on the CDN. But after a little digging I found the problem: Moz simply does not support SSL certificates served from a CDN such as CloudFront or CloudFlair.

This response was posted by James Kaiser, a Moz Inc employee, on a Moz forum:

Hey there – sorry if there was a miscommunication but we do in fact support SSL, however at this time we do not support SNI (Server Name Identification) which is a technology used to host multiple SSL certificates from a single IP address. If you are currently leveraging CloudFlare or CloudFront we will not be able to crawl your site. If you are using a standard SSL from it’s own IP we can most likely crawl that page.

This is a major disappointment to me as I was enjoying using Moz Pro and am now weighing up whether to keep shelling out the monthly subscription. Moz has said they are working on a fix but that ‘an ETA is not available quite yet’. That was back in July and as far as I’m aware there have been no other announcements.

So if you are facing the same issue what can you do? It seems to me that there are few options:

  1. Live with the fact that you will no longer get SEO errors reported despite paying for this feature.
  2. Ditch the SSL certificate on your site (Bad option in my opinion)
  3. Ditch the CDN (Very bad option)
  4. Cancel Moz Pro

I think I’m going to go with option 1 for the time being as there are plenty of other useful features included in the Moz Pro subscription but if they don’t provide a fix in the next 2-3 months I may well start looking around at other options.


Hide your WordPress username for extra security

I love WordPress but there are a few defaults which aren’t great from a security point of view. One obvious example is the way that WordPress makes your username visible to the whole world in the slug of your author archive which generally appears at There is often a link to this URL included on every single post you publish making it extra easy to find. To avoid the chance of some malicious fool gaining access to your site you should hide your WordPress username to keep both your password and your username secret.

What WordPress is actually showing in the author URL is what’s called your ‘nicename’. Your nicename is stored separately in the site database and matches your username unless your username contains any special characters. WordPress sets this to match your username automatically when your user account is first created and uses it in the aforementioned author URL. Which is a bad idea as it gives potential attackers a head start on gaining access to your website.

Hide your WordPress username by removing it from the author URL

If you have access to your website’s database it’s very simple to change your ‘nice name’ and thereby replace the username that appears in your author archive with something else. If you use a GUI like PHPMyAdmin or MySQLWorkbench just go to the users table (by default called wp_users) and find the row for your account. You should see columns for user_login, user_pass, user_nicename and some others. You can change the entry from user_nicename to anything you want but as this is where you do want to be identified it makes sense for this to be you first name or full name.

You want to end up with something like this:

ID user_login user_pass user_nicename
1 notyourname somethingreallysecret yourname

If your user_login and user_nicename are both already set to your first name or full name I’d strongly recommend changing your user_login to something more secure. You can do this from this table too. The only thing your user_login should be used for is logging in so it doesn’t need to be short or look cool. Just don’t try to change your password here, you’ll need to do that through the WordPress settings page.

Changing your WordPress nicename with a plugin

I prefer to make these sort of changes to the database manually but if that’s not possible or you don’t feel comfortable making edits to the database directly then using a plugin is probably the better option. Install and activate the Edit Author Slug plugin and you’ll find you can change your username very easily. This plugin also allows you to change the ‘author’ part of the URL meaning you could, if you wanted, direct people to an archive your posts at

Redirecting your old author URL to your new one

If your old author URL has been listed in search engines you may want to create a 301 redirect from the old URL to the new one. You can do this at the web server level or with a plugin such as Simple 301 Redirects.


Why we moved to CloudFront Content Delivery Network

A couple of months back I broke our website. I didn’t mean to, and I should’ve know better, but one quiet Thursday evening I broke our website. It’s what’s known as a success disaster. Apparently.

All I did was write a short blog post about the new Raspberry Pi Zero which had just been announced that morning. In case you don’t know the Pi Zero is a computer that fits in the palm of your hand and it was being given away free with a magazine — and the regular price for the Zero is just £4! This is obviously very cool so I wrote a short post, stuck it on our company website and tweeted the following:

Then the magazine retweeted it (despite me getting their Twitter handle wrong, it’s actually @TheMagP1) and a few folk clicked through. Nice! Then the Raspberry Pi foundation retweeted it. They’ve got about 250,000 followers. My phone was buzzing every few seconds to announce further retweets and likes. And hundreds of people clicked the link to read my blog post! I was really pleased until I realised our website had gone down.

Which lead to…


I was completely unprepared for such an influx of traffic despite warning clients of such a possibility in the past. To be honest, I never really expect people to read my blog posts. I mean people do, but usually we’re talking tens of people not hundreds. And certainly not hundreds within the space of a a couple of minutes. At first I couldn’t figure out what to do. I thought about asking Raspberry Pi to delete the tweet but this felt like my moment of Twitter fame (silly I know) and I wanted to cling onto it. Then I realised, I had also put the blog on Medium. If I could just send the traffic there instead everything would go back to normal. I set up a redirect from our website and breathed a sigh of relief as our little server perked right up again. Everyone who now clicked the link was able to read the post on Medium but this was traffic that could’ve been on our website and I’d lost it.

What could I have done to prevent this?

There are a few things I could’ve done to save myself from this problem.

Option 1: Not write the post in the first place

Nothing would’ve gone wrong but (and this is for those of you who like Bible references) I would’ve been like the servant that buried the money that time. I wouldn’t have lost anything but I wouldn’t have gained anything either.

Option 2: Used a custom URL shortener

A custom URL shortener is a simple little webapp that redirects people from one URL to another. Media outlets use these a lot to ‘brand’ links on social media. So you might see a link like this: but when you click it you actually end up here:

Short links like this can also hide tags which provide extra info for analytics tracking (e.g. ‘smid=tw-nytimes’ in the example above). Had I included a redirected link in my original tweet I could have easily changed the destination URL to alter where people ended up after clicking it. This is similar to what I actually did here but it would’ve been easier for me to put things right quickly. There are various pros and cons to link shorteners which I may explore in a future post.

Option 3: Use a Content Delivery Network

This is what I actually should have done in the first place. A Content Delivery Network (abbreviated to CDN) is basically a service which copies all the files from your website and distributes them to several servers across the world. This means that no single server ever gets hit with too much traffic. It also means that your site will load much faster for various reasons including the fact that users get the copy of your site stored closest to them geographically. Using a CDN really is the best option for most websites (perhaps all sites?) and I’ve now set this up for ours. Why hadn’t I just done this as standard? Honestly I thought it would be complicated and time consuming. And it was a bit the first time. But so is trying to figure out what to do when your website gets knocked offline by people actually reading the damn thing. I’ve set up a few sites on the CloudFront CDN now and it’s pretty straightforward once you get used to it. And it’s so worth it. I no longer have to worry about our website going down at random times.

Most importantly of all I should have believed more in the content I wrote. Well over 600 people clicked the link to my post and my original tweet got loads of retweets and likes. I wrote that blog post because I was seriously impressed with what Raspberry Pi are doing. It’s not the greatest blog post but I guess that’s the point: It doesn’t have to be.

So here’s my lesson to myself: Don’t worry about ‘writing great content’ just write something real that you care about. You probably won’t get hundreds of readers but you should definitely have a good web hosting and move your site to a Content Delivery Network just in case.