This is a guest post by Adam Bate. Adam is a young online business owner and Internet marketing enthusiast. Adam runs a web hosting company, Web Savers, and has recently started the Canadian Web Design Headquarters – a site dedicated to connecting web designers, agencies, and freelancers with potential clients. Adam has hosted WordPress websites for close to a decade and knows the ins and outs of hosting a WordPress website.
When you’re searching for a home for your website, it’s important to do a bit of research before rushing into your buying decision. Not all web hosts are created equal and it’s important to ask the right questions.
So many people simply sign up to the cheapest web hosting package they can find, or the first one that they stumble across. While this might be okay if you are running a personal website or blog that is not crucial to the success of a business or income stream, it is not okay if you are hosting a website that you used to make money.
Here are three of some of the most important but often unasked questions you can ask your web host to ensure your website’s security and reliability.
Is PHP run as an apache module or FastCGI?
This might not make any sense to you reading this, but it is a very important question when it comes to the security of your website – especially when on a shared web hosting server and if you run WordPress with multiple plugins.
If PHP is running as apache there are certain permission tweaks you will need to do in order to let PHP access the files on your website. One of the most popular ways to do this is to change the file permissions of a folder to chmod 777 – which basically means any user can read and write to this folder and execute anything within it. This lets you upload files automatically through scripts and plugins within WordPress.
However, if a separate website on the same server were to be hacked, your website would also be compromised because of these set permission since they are letting anyone write and execute code to your files without you even knowing. This is a very popular method of malware injections. Even though your website does not have any specific vulnerabilities, it can still be compromised due to permission settings on a shared web server.
When PHP is being run as FastCGI, the processes will be owned by your specific user and not Apache. This means that WordPress will be able to read, write, and execute your files withing having to change the file or folder permissions. This is a huge plus for the security of your website.
Does your unlimited web hosting really mean unlimited web hosting?
This has been one of the hot topics of hosting websites for a number of years. Most web hosts offer some sort of package that includes unlimited resources – such as disk space and transfer.
Most do this as a way to give their clients peace of mind and because most people and websites do not use as many resources as they think they will.
However, it’s obvious that no web host can offer a truly unlimited service. Even on a cloud-based hosting solution, they are still limited by the entire array of disk space and the total transfer of their connection speed.
Make sure to check the terms of service or ask the company if unlimited really means unlimited. In most cases, if your website uses too many resources – weather it’s too much bandwidth or too much CPU usage, they will simply shut down or suspend your website and account and make you upgrade to a more expensive plan.
Unfortunately most people don’t realize this until it’s too late and they wake up one morning and notice their website is offline. It doesn’t matter how great a company’s uptime is if they will suspend your account without notice.
Is your backup service a true backup service?
Most web designers and hosting companies will set you up with a package for your website that includes or advertises some sort of daily or weekly backup solution. Unfortunately for most people, what they don’t understand is that most of these backup solutions do not include data recovery and some do not even backup individual files.
If a company offers a backup solution but doesn’t provide data recovery, you will typically have to pay an up-front fee in order to get your data restored. The backup process is the only “included” part, not the recovery process.
Some web hosts only do full-server image backups which do not even allow for individual files to be restored. In these cases, the backup simply takes a snap shot of the entire server and does not copy or back up each individual file. Although this is great in case anything were to happen to the entire server (such as a server-wide hack, or a hard drive failure) it is not so great if you were relying on this advertised service as a way to restore lost files.
Needless to say, not all web hosts offer the same level of service. It’s important to ask the right questions before choosing a hosting plan for your WordPress website. Doing a little research before making a buying decision is sure to save you a lot of headache and hassle down the road.
This is a guest post by Chris Stott – a WordPress Web Designer & Consultant at Really Simple Web. He helps small businesses grow online using WordPress by keeping things simple and actionable. You can sign up for his awesome free newsletter here. I’ve been in touch with Chris on and off for quite a while – he’s a great guy who does great work.
At sometime throughout your career of running a WordPress website you are likely to need to move to a different host for some reason or another. Hopefully, this will be because your site has out-grown your current host and you require something more powerful. More often than not, hosting companies upset people in some way and you need to move.
I find that people don’t switch and put up with an expensive host they have been with since they started out as they are daunted at the prospect of moving to another provider. Fortunately Code Garage makes the process much easier when moving a WordPress site!
In this post I’m going to show you how to move your site from one host to another quickly and easily. If you need to move hosts, don’t put this off. Just dive in.
You need to have 2 things in place.
Your going to need a couple of bits of software to make this process easier, don’t worry they’re free.
Once you have these things in place you are ready to move your site.
It’s worth doing a bit of spring cleaning on your existing site such as getting rid of plugins, spam comments, themes and more that you don’t need. Also you might as well make sure WordPress and all your plugins are fully up to date. This is just a good opportunity and means you have less stuff to move. Remember that once you do this you’ll need to wait for another backup cycle so that Code Garage has the latest backup of your new site. All this means that when it comes to start the transfer we have a nice clean backup to work with.
There are two files you are going to need to download. Your latest ‘Files’ and your latest ‘Database’. Remember that once you download these to your computer they are snapshots of your site at the time of the last backup. If you get delayed in moving your site, you might want to start with the latest backup as Code Garage will continue to run in the background of your existing site until you complete the transfer.
This is about as technical as it gets, and it’s not that daunting I promise – I’ll walk you through every step. Unfortunately you can’t quite just copy and paste your files, you need to create a fresh database on your new host.
Here’s what I need you to do. Most of you, I imagine will have hosting with a cPanel backend, if not (mine is xTend backend) you’ll find they are very similar.
To create a new database you can either use the wizard (1 in the image below) or you can go in to myPHP admin (2 in the image below) yourself and do it from there – note that some hosting won’t have the wizard, so just use php MyAdmin (2) to do this. You’ll need to make sure that you make a note of the database name, username and password created as you’ll need this information in a bit. It’s easier to just save it in a text file so you can copy and paste it later. Note: Your Database name and username are often the same.
Next you are going to need to import your existing database (the .sql file that you downloaded from Code Garage) in to your new database (the one you just created). This is easy. Head over to phpMyAdmin in your hosting cPanel. Select the database you just created (this is important as I sometimes forget this step and get errors).
Now import your Code Garage database backup (the sql file) to that new Database.
The final technical step of getting your new database ready is to tell your WordPress site how to access the new database. To do this you are going to need to manually edit some files.
Unzip that Code Garage backup of your site files that you have (you’re going to need to do that ready to upload them anyway).
Navigate to the file wp-config.php file in the root folder and open it with a text editor.
You want to navigate to the database details which are near the top of the file. Here you are going to want to change the database details: database name, user and password to those of the Database you created on your new host. Save that file over the existing file so it becomes your only wp-config.php file in your folder (make sure that you save it in the same format don’t let your text editor convert it to rich text or anything).
Right that’s your database setup, we are now ready to upload the rest of your site to your new host.
You are going to need to use an FTP programme for this step. You should have your FTP login information in your welcome email from your host, otherwise you can setup FTP users via your hosting control panel. Some hosts will require you to unlock your FTP access either by time period or IP address, so you’ll need to do that to get access.
Put your FTP details in to your FTP programme and let’s get connected.
You are going to navigate to your new site location on your server. Depending on the type of hosting you are using this will probably be the Public_HTML folder under the folder for the new site you’ve allocated to your domain.
Once you find this make sure that you delete any files within that folder. Again, depending on your host, this could be an index.html file or similar.
Now upload the contents of your Code Garage backup of your files that you have unzipped so that becomes the contents of your public_html folder. You want to upload at the level where your wp-config.php file is. You can select all files using CTRL+A on a PC or CMD+A on a Mac.
Here’s where we wait for the files to upload.
All the folders look like they are in the right place (they should look like the image below) and it’s worth opening your wp-config.php file on your new server to check that it has the right DB names etc.
Let’s recap where we are. You currently have a new host with a new database setup and your existing database imported in to that. You also have all your files uploaded to your new server, in the right place, from your Code Garage backup. You’ve edited the wp-config.php which got uploaded to your new hosting so that it has the new database details.
For the moment however your site is still operating from your old host. It’s time to make the final switch to your new hosting. This is where we tell your domain name to point at your new host. This requires you to change your DNS settings with your domain registrar.
A word of warning before you do this. Your DNS settings will also control your email. If you’ve just got a forwarding address that’ll be fine, but if you have added Google Apps or a particular inbox you are going to need to make sure you provision the changes for that as well. You’ll need to edit the MX records on your new host prior to the switch. Find out more about moving Google Apps to a different host here.
Within your registrars domain management site, navigate to the domain we are dealing with and then select DNS setup or equivalent. I use Namecheap so this is what it looks like for me:
Now you just need to update your DNS settings to point at your new host and then wait for your site to switch. This can take around 24 hours but is usually much quicker.
Check everything is working, check all the right plugins are active, have a click around.
It’s worth keep your old host running for a week or so until you are happy everything is running fine on your new host, because if you have a problem you can easily switch the DNS back to your old host.
There you have it, using this guide and your Code Garage backups it is easier than you think to switch your hosting to a new provider.
I hope you found this guide useful. If you have any questions please leave a comment I’d be happy to help.
Addon Domains. So alluring. Pay $7.43/month, host 67 WordPress sites. It’s a siren song for cash strapped internet marketers.
Essentially all of the major shared hosting providers offer addon domain schemes – to the point that this is an expected feature of hosting. The gist is: You buy a hosting plan, and you can host large (sometimes unlimited) numbers of domains on them – as long as you fit inside the disk space, bandwidth, and CPU limits set by your host, there’s no problem. Unsurprisingly, people take advantage of this. I know, because we see these servers when we go to clean malicious code off of them. Occasionally we’ll find a server with 1 site on it. Most commonly, it’s somewhere between 2 and 8 sites. Maybe 20% of the time we’ll see somebody with 15-20 sites. And then, once a month or so, we get a whopper. 50 sites. 100 sites. More.
So what’s the big deal? It’s permitted by the host, you’re within your expected limits, so what’s the problem? The problem (ok – one big problem) is Cross Site Contamination. I didn’t know what to call this phenomenon for a long time, and I recently heard Sucuri use that term – it’s fitting. In most cases, when a host sells an “addon domain” (Note: I’m specifically not referring to “reseller” plans, which generally don’t suffer from this), the setup works like this:
Your host has a server (which is just a computer, not *that* unlike the one you work on), which is running special software to partition it into hundreds or thousands of “accounts”. These accounts are segregated from each other, so you can’t access the files on other customers’ sites. However, when you set up on addon domain, this site is going into your account, along with all your other sites. These sites have access to each other – a plugin installed at my site blue-widgets.com could access the files on my site at purple-widgets.com, assuming they’re addon domains on the same account.
To illustrate:
A few weeks ago we saw what I think was our biggest server ever – 152 WordPress installs. The server hummed along just fine until one day, a hacker managed to find a vulnerable timthumb installation in one of the sites, and used that to switch every single WordPress install on the server to foreign political propaganda. Needless to say, her client (these sites all happened to belong to one client) was not pleased to wake up the next day and see their business websites being used as a platform for these messages.
Because these were all addon domains, every single one got hit. Instead of dealing with the one site with a vulnerability, every single one had to be scanned, cleaned up, and tested. It was a terrible day for her, and them.
Aside from that, we were now tasked with cleaning up a site with 500,000+ files on it. Each one needed to be scanned and vetted, and cleaned up if there was a problem. It took hours to get cleaned up because of the sheer size of the server, and then entire time, she had the client breathing down her neck.
If all of these sites were separated, she’d have had one site infected, and we likely would have had it cleaned up in less than an hour.
You’ve probably guessed where this is going. Everything is fine as long as all of your code plays nice, and only tinkers with files that it’s supposed to. But what happens when a hacker manages to get a backdoor on one site, and that backdoor has access to all of your other sites? I want to make this absolutely clear, so I’ll spell it out: A hacker with access to one domain will infect every addon domain on the server.
Here’s the deal: Your website is inherently insecure. For the majority of sites today, it’s a safe bet that at some point, you’re going to get malicious code. That’s cynical, but it’s true, and you should recognize it. Over time, the likelyhood that you’ll forget to upgrade WordPress, or install a plugin that wasn’t vetted properly, or miss an email about a vulnerability discovered in the theme you use goes up. Odds are, you’ll get caught with your pants down at some point.
So, if the odds are that you’re going to experience trouble on any given site, say, once a year (Hypothetically. Don’t quote me as saying that any given site will get hacked once a year), what happens when you have 2 sites that have access to each other? And, each time a hacker hits either one of them, they both get infected? Your sites are now infected twice as often. What happens when you have 20 sites on a server? 100? You end up spending as much time dealing with hacks as you do building your business. This can literally sink you.
You can make sure your sites don’t have access to each other. For most site owners, the best way to do this is to move over to a reseller plan. Reseller plans segregate your sites enough that hackers no longer have ludicrously easy access to every site on the server if they manage to find a hole in any one of them. It’s not a bulletproof solution – if the hacker can break into your host, or they get your main account password, they may still be able to get at all of your sites – but these situations are very rare compared to addon domain cross site contamination.
I thought you’d never ask.
So, there you have it. There are a couple of caveats to this article, but the basics are: If you have lots of websites that you can see when you log in via FTP, you’re playing a risky game.
Have questions about your specific setup? We’d love to talk to you about it. Email us at help@codegarage.com, and we’ll try to get you back on the straight and narrow.
Recent Comments