Finding Great Web Hosting

Thoughts On The Best Web Hosting I Have Found...

Using Google’s New Asynchronous Tracking

Recently Google has made a new form of their tracking available that should provide some better performance. Normally a webpage can experience slowdown while downloading or executing JavaScript (which is what the Google tracking uses). To be more correct, any time you are loading something from another domain you do run the risk of having it introduce itself as a bottleneck for your page speed.

I have always found Google’s tracking code to be fast, definitely faster than other tracking applications I’ve tried. Still, if they can improve the performance even further I won’t turn it away.

Installing Google’s New Tracking

I found that just relocating the tracking page was a little tricky…not sure why they hide it the way they do. Anyway, here are the steps to install the new (and potentially faster) Google tracking:

  1. Log into your Google Analytics account

  2. You should be provided a list of sites you are tracking. Find the site you want to change.
  3. You should see your site URL and then an identifier that looks like this: UA-1234567-8. Write this identifier down (it is your sites Web Property ID).
  4. Click the Edit link.
  5. In the upper-right of the page that has loaded you should see a link “Check Status”. Click on this.
    google analytics: check status

  6. You should now see a new link in the section titled “Instructions for Adding Tracking” that says something like “Try the new Asynchronous Tracking!” – click on this.
    Note: at some point this new feature will likely become a standard feature so this link may be moved or changed but accessing the tracking code should still be available at this page

  7. You should now be presented with the page to access the new code. At this time, you have to manually enter your Web Property ID (which is why we wrote it down earlier). I imagine they will at sometime change this so the code presented to you will already have your ID in it.
  8. Copy the tracking code text.
  9. Find where you keep your old Google tracking code (for example, in WordPress this is normally in the footer.php in your theme).
  10. Remove the old Google tracking code and replace it with the new
  11. Remember: You will need to update the Web Property ID. The line you need to change looks like this:
    _gaq.push(['_setAccount', 'UA-XXXXX-X']);
    So on this line you would replace UA-XXXXX-X with UA-1234567-8 (using the example code from above)

  12. Save the file you’ve changed and ensure the changes are copied to your web server.

The process is relatively simple, although I do think Google should just be populating the Web Property ID themselves. Seems likely to me that many people will see the new code and replace their old code with it without ever reading that they need to replace the UA-XXXXX-X.

What Does Asynchronous Mean?

Normally, when a web page hits some JavaScript it has to wait for it to download before it can move on. This is why people try to put much of the JavaScript at the bottom of their web pages: this way, it is creating the slowdown after everything else has been loaded and hopefully the user won’t notice the slowdown. Asynchronous just means that the web page will continue to load other items even when it hits this piece of JavaScript. Not only should this improve performance, it means you can put this piece of JavaScript anywhere you want instead of the bottom of the page.

Additional Reading:

Manually Correcting the GoDaddy Wordpress Virus Ninoplas

A large number of WordPress sites at GoDaddy have been being hacked recently. After the site has been compromised, all traffic to the blog is being sent to either a web page that attempts to deliver malware to the visitor or will redirect the page to search results, such as Bing search results for anti-virus.

Shortly after the virus was first identified, someone helpful at Inspirated.com released a script to fix the problem. Fixing the process manually is very difficult because when the site is compromised, every PHP file is updated with a script that causes the redirect. This means to fix the problem you would need to edit every PHP file by removing this redirect (which often appears as the first line in each file as a base64 method).

While I imagine the script provided by the site above works great, I had manually fixed my WordPress blog when I was hit by this problem. I’ll discuss how I manually addressed this problem for those who would prefer to address the problem by hand.

Manually Addressing the Ninoplas Hack

These are the steps I followed. I’m not going to say they are the best steps but they are the ones I used. My blog is hosted in a directory named “blog” so these instructions will be based on that. If your blog is hosted in another directory or in the root, you’ll need to adjust your steps accordingly. Also, you will need a backup of your site’s files to follow these steps. These steps are intended for those familiar with configuring WordPress.
1. First, you need to set your site into maintenance mode. There are plug-ins and in-depth guides for doing this but if you need to do this quickly simply:

  • Create an index.html file that states your site is under-going maintenance and will be back soon

  • Upload this to your blog’s directory (the same directory as wp-config.php)
  • Rename the index.php to index.old (or something else)

Now when people visit your site they will see the index.html. This also protects your visitors from being redirected to wherever the hack was sending them so you should do this when you begin.
2. Create a new directory called blog2
3. Upload your clean backup of WordPress files to the blog2 directory.

  • If your theme has changed since your last site backup, download your theme files from your original blog directory (which currently still has the malware in it). Open every PHP file and remove the first line which will be a line of PHP often using the Base64 method. After you have fixed every PHP file, upload your theme files into the theme directory in the blog2 directory.

  • If you have added any plugins since your last site backup, I recommend simply re-installing each of these through WordPress itself and reconfiguring them there.
  • If you have added images since your last backup and are not using a CDN (you would know if you were using a CDN so if you’re not sure, you’re not using one), you will need to download your wp-content/uploads directory and then upload those to the blog2 directory

4. Rename blog to blog_old and rename blog2 to blog
5. Verify the site is now working. I would recommend backing up the hacked version of your site just in case you missed something. After you have a backup stored locally, I would remove the bad version of your blog from the site.

Are the users really the source of this problem?

Many reasons have been listed as to why people be hit by this problem such as using PHP4, having weak passwords, using incorrect file permissions, etc. My problem with this is that I didn’t fit into any of the categories that have been provided so far. My password was literally a string of nonsense characters I generated using a password tool. My GoDaddy account had been on PHP4 but I upgraded it to PHP5 a few weeks before I saw this problem because I wanted to begin using SSH. I fit none of the reasons given for why a user would be responsible for this problem occurring.

I wonder this: is it possible that many of the compromised sites do have these problem areas but that these problem areas are not the reason they have been hacked? I know that, at least in my case, it seems that everything being listed as a weakness is not something I needed to correct

Why Only GoDaddy?

Assuming this is a problem universal to WordPress hosting, such as incorrect file permissions or weak passwords, then why is the problem only (or predominantly) occurring with GoDaddy hosting? Wouldn’t identifying and attacking GoDaddy-only sites be more difficult than hitting any self-hosted Wordpress site at all? In other words, is it reasonable to believe that a hacker would find a WordPress site with a weakness but then, because they realize it is not hosted at GoDaddy, they decide to leave that site alone? Do hackers really show this type of preference when trying to break into a site? Does the host really matter for their purposes? I am a little skeptical that somehow identifying and then attacking only GoDaddy sites would somehow be easier or preferred. My personal conspiracy theory is that someone out there figured out how to attack all the sites on a particular shared server. In other words, they’ve gained access above where my site files were located and were then are able to attack my site, regardless of how well or how poorly my security was.

New Web Hosting

I found it concerning that: a) my site was hacked but b) my site did not fit into any of the security weaknesses listed. Because there appeared to be no solid answer as to why it happened to my site, it seemed to me that there could be no guarantee that it wouldn’t happen again. GoDaddy had also taken the stance that it wasn’t their fault (which I understand if it really is user errors in security) and they were sending out the message that users would need to fix their sites and improve their security. To me, continuing to host here sounded risky.

I had been researching new hosting options already and knew I wanted to move my old sites to HostGator, this even just gave me the excuse to do so. Shortly after doing so, a second wave of hacks hit WordPress sites on GoDaddy again, this time a different flavor of the same problem. Then people started complaining that their sites were being hit repeatedly with the same problem again…even after implementing all of the fixes suggested. I heard around this point (the beginning of May) that GoDaddy started taking this problem pretty seriously. I’m no expert and I can’t say that GoDaddy was suffering from some kind of internal problem but comments like this seem to make it less and less likely that users are really at fault.

My thoughts now are that I am so glad I moved to HostGator after the first attack. My performance has improved, the support is phenomenal and I’ve not been hit by any problems since the move. I realize moving to another host won’t solve any problems if there is some core issue with my security settings or with Wordpress, but my paranoid personality can’t help but feel that this problem goes deep than individual my settings. So far, the move has proven to be the right choice.

Moving Your WordPress Blog to HostGator

My first experience with HostGator was moving a WordPress blog to HostGator. I had maintained this site at another hosting company for several years but after some slow performance and a few technical issues I decided to give HostGator a try. In retrospect, this was a great decision as everything with HostGator has worked out great.

Getting Your HostGator Account

The process of purchasing your HostGator account is straight-forward. I do want to cover a few points about this process though:

  • If you are looking for improved database performance over a standard shared hosting option, I recommended the Reseller Account. Even though I am not a hosting reseller, I purchased this plan simply for the improved database performance. It does cost $25, which is outside of the price range for many of us. However, if you’re looking for a step up from shared hosting but aren’t ready for the more dedicated server options I think the Reseller Accounts make a perfect stepping-stone.

  • After purchasing your hosting you will receive an email on how to change your domain name servers to point to your new HostGator hosting account. You won’t want to do this just yet though, that will come later.

Transferring All Files To Your HostGator Server

The process here is fairly simple: you will want to download all of your files from your current host to your computer. You will then upload all of these files to the public_html directory in your HostGator account. Keep in mind: at this point you will need to use the IP address of your HostGator account to connect to FTP. On a side note, this stage was where I saw my first real difference with HostGator compared to my previous hosting provider: even FTP activity was so much faster with HostGator.

Note: You can have the files transferred for free for you by filling out this form (within the first 30 days of your new account). This is a great option if you are not comfortable moving your files however I prefer to have control and moving the files yourself means you will not have to wait.

Setting Up Your WordPress Database

The first thing required in the database setup process will be a backup of your current database. Generally speaking, backups are the sort of thing you should be doing on a regular basis. If you are not familiar with creating backups, I recommend the following process:

  1. Log into your WordPress admin area and click on Plugins.

  2. Next click on Add New.
  3. Search for “WP-DB-Backup”. This is my preferred backup plugin. If you see multiple results or are confused by which plugin to install, look for the one created by Austin Matzko.
    install backup plugin

  4. Install and Activate the plugin.
  5. Click Tools and then Backup.
  6. In the top box, you will see the default options for which tables will be backed up. There is also the option to backup other tables, normally those created by plugins. I have never had to backup any of these tables but if you are unsure you should select to back them up.
  7. In the next box down select email and then enter your email and click Backup Now! The backup will be emailed to you. I normally do the email option so I have the backup available in my email later if I need it but obviously if you prefer you can also download the backup directly to your PC.
    backup now!

Creating Your Database at HostGator
Next, you need to create your database on HostGator.

  1. In your hosting cPanel, find the Databases section and click on MySql Database Wizard.
    mysql database setup at HostGator

  2. Enter your database name and click Next.
  3. Next enter you User Name and Password – I would recommend using the password generator as this will ensure the password is very strong. Then click “Create User”.
  4. On the last screen you will grant all the rights this user and click Next. You now have your database and database user created.
    Setting HostGator WordPress Privs

Restoring Your WordPress Database
Next, you need to restore the backup of your original database made earlier in these steps:

  1. Again in your control panel browse to the database section and then select phpMyAdmin.

  2. Click on your newly created database (which should appear in the left)
  3. Click on Import
  4. Click Browse and select the file that you either emailed to yourself of downloaded to your PC
  5. Click Go and your database should be restored.

Your WordPress database should now be restored to your HostGator account.

Reconfiguring Your WordPress to Use Your New Database
You will now want to browse to your WordPress installation and edit the file wp-config.php. You’ll need to change your Database Name, User Name, and Password to the newly created database and account. Also, your DB_HOST should be set to “localhost”. Some hosts require you enter a specific database name but at HostGator you will use localhost. Your config file will look something like this:

/** MySQL database name */
define('DB_NAME', 'hostingusername_databasename');

/** MySQL database username */
define('DB_USER', 'hostingusername_databaseuser');

/** MySQL database password */
define('DB_PASSWORD', 'SuperStrongPasswordHere');

/** MySQL hostname */
define('DB_HOST', 'localhost');

Remember that HostGator precedes your database name and user with your hosting account user name. So if my hosting account name is gatorfan and my database name is database1 then the DB_NAME would be set to gatorfan_database1.

Testing Your WordPress Blog (optional)

Testing is a little trickier than just loading the web page. These steps are for those who want to be absolutely sure that your WordPress blog is working and these steps are optional.

First, before you have updated your domain, you will need to access your site through the following address: http://ipaddress/~username/. So if your web server IP address were 127.0.0.1 and your username were gatorfan you would access your site with the following address:
http://127.0.0.1/~gatorfan/

Keep in mind that if you have your WordPress installation somewhere other than the root, you will need to include that in the address. For example, if you place WordPress in the “blog” directory you will use: http://127.0.0.1/~gatorfan/

At this point you will probably see your site but ever page will show as 404 (not found). This is because WordPress will need temporarily updated to fully test:

  1. Open your phpMyAdmin again

  2. Click on your database
  3. On the left, click on the table wp_options
  4. On the browse screen you need to find two options. The first is siteurl and the second is home. Both of these should currently have your site url which will looks something like this:

    http://yoursitename.com

  5. On each of these options click the pencil icon to edit the entry and in both cases change the value to http://127.0.0.1/~gatorfan/ (obviously you will want to enter your IP address and user name). The point is to change the address to the address you are currently using to preview the site.
  6. Now you can verify the site, test your plugins and so on.

WHEN YOU ARE DONE TESTING BE SURE TO CHANGE THESE SETTINGS BACK!

Updating Your Domain Nameserver

Now that everything is updated and tested, it’s time to update your domain to point to your HostGator account. HostGator has some great guides on doing this for some of the most popular domain companies (including videos which are very helpful).

After this point, you just wait. One “trick” I do at this point is I edit my WordPress footer and add a period or some other symbol to the bottom of my web page. I then check my website over the next few days and when I see the period or other symbol appear at the bottom of my site I know I’m now seeing my site on the new host.

Now just because you’re seeing your site on the new host doesn’t mean you should immediately cancel your old host. I would wait another day or two to ensure everyone is seeing your site on HostGator.

Congratulations! You now have your blog running up on HostGator!