Posts Tagged ‘1and1’

How to point 1and1 domain to HostGator hosting

Friday, May 27th, 2011

Using HostGator for your web hosting, and 1and1 for your domain name is not too difficult to set up.

Configure HostGator so it knows about the domain name

First of all you have to make sure that your HostGator hosting account knows about the domain name. If you have already added the domain to your account by either setting it up as the primary domain or as an addon domain then you need do nothing further at the HostGator end.

If you haven’t done this then log into your HostGator cPanel. Then in the Domains section click on Addon domains.

hostgator cpanel

Enter your domain name and all the other details you need and click on Add Domain.

hostgator create addon domain

Configure HostGator so it knows about any email addresses

Whilst you are in the HostGator cPanel configure any email addresses for the domain name. Once you point the 1and1 domain to HostGator, 1and1 will no longer be responsible for collecting email to this address. HostGator will now have control of the email, so setting up any email boxes in advance to save you from losing any emails.

Configure 1and1 to point the domain to HostGator

Login to your 1&1 Control Panel. Click on Domains.

1and1 domain settings

Select the domain name you want to point to HostGator and click Edit DNS Settings from the DNS pull down menu.

1and1 edit domain dns settings

You’ll get a warning saying the following.

Please note:
Full functionality cannot be guaranteed if you choose DNS settings other than the original 1&1 settings, such as e-mail and web space. Domains can be (re)set to 1&1 default settings by clicking Reset

This means that if you change the name servers to point to HostGator then 1and1 will no longer be hosting your website, or your email. You will have to configure both your website and email via HostGator from now on.

Select the option for ‘My name server’.

1and1 point domain to hostgator hosting

Then enter the HostGator name server names (there should be two of them) into the boxes. You can find the name server names on cPanel.

hostgator name servers

Then confirm the settings on the 1&1 Control Panel. You’ll get a message saying it will take some time for the settings to take effect. This could be 24 hours, or even more depending on what DNS server you are using. After changing the settings keep checking the new domain so you spot when the changes are live you for. But beware – just because you can see the new site doesn’t mean everyone can. Leave the old site in place for at least 48 hours so you can be sure that all DNS records have updated.

Advanced topic – minimising downtime

If there is already a live website at your original 1and1 hosting then you might have to think about copying the files over to HostGator before updating the domain to minimise any website downtime. This is fairly easy to do if your website just contains static HTML files.

If however you are moving a dynamic website there is a lot more to think about.

Whilst the DNS settings are propagating some people will see the website from the 1and1 hosting, and others from the HostGator hosting. What if someone posts a comment on the 1and1 hosted site, and someone else posts on the HostGator site? It could be a nightmare to merge all the comments back together. You may therefore want to consider setting the old (1and1 hosted) site to read-only by disabling all new comments on it.

A further difficulty is that moving a dynamic site requires more than just moving the files. You will have to create new databases, import the database tables and maybe customise .htaccess files or other config files if the configurations need to be different between the two hosts (which is often the case).

One way to work around this is to set up the new version of the site in full at the new hosting provider using a secret dummy domain name. You can register a domain just for this purpose if you don’t have a spare one that isn’t in use. Just make sure not to tell anyone about it, and even better protect access to it to just your IP address using a .htaccess file.

There are a lot more complexities involved in moving a live dynamic site from one host to another. If you want more information about moving a WordPress blog between hosts have a look at

Compressing HTML and PHP files on 1and1

Friday, July 9th, 2010

1and1 doesn’t have mod_deflate or mod_gzip enabled on its home or business shared server packages which means that many of the usual .htaccess tweaks to compress your web pages won’t work. Here’s something very simple tweaks that will work with 1and1, and with other hosts too.

Set up your .htm and .html files so that they are parsed by the PHP interpreter by adding this one line to your .htaccess file.

AddType x-mapp-php5 .html .htm

Then create and upload a php.ini file to your websites root directory. If you are using WordPress then this should be the same directory as the one where wp-config.php is.

The contents of the php.ini should be as follows.

zlib.output_compression = On

This line causes PHP files to be served as compressed if the browser supports it. And as we have registered .html and .htm as being PHP files they will now be compressed.

You can test that the HTTP compression is turned on by using this simple HTTP compression checking tool, or by using the more comprehensive Page Speed add-on for Firefox from Google.

Here are the results from the HTTP compression checking tool showing that compression is now on, and that the home page HTML is being served using 76% less data. Note that this saving refers only to the HTML page, and not to any other images, style sheets, or JavaScript.

rml gzipped on 1and1

Increasing expiry time of images on 1and1

Another quick tweak you can make to your .htaccess is to increase the expiry time of your images, and other data files. This will result in quicker loading times for regular visitors as the files will stay in their browsers cache for longer.

Add this to your .htaccess. You can increase the expiry times if you don’t think those files will change.

#Increase cache time for resources

ExpiresActive On
ExpiresByType image/gif "access plus 2 weeks"
ExpiresByType image/jpeg "access plus 2 weeks"
ExpiresByType image/png "access plus 2 weeks"
ExpiresByType image/ico "access plus 2 weeks"
ExpiresByType text/css "access plus 2 weeks"
ExpiresByType text/javascript "access plus 2 weeks"
ExpiresByType application/x-javascript "access plus 2 weeks"

Use Google’s Page Speed add-on to verify that this has worked. Go to the Resources tab to see the headers for each individual file served from the HTTP server. Below you can see the current date/time, and that the expiry time is set two weeks into the future.

expires date for image

Caching and expiry changes combined

Here are before and after results for Google’s Page Speed tool of applying both the above changes to another of my websites. You can see that these quick changes give the website a small increase in score.

website score before

From 88 to 92.

website score after

This isn’t a big jump, but it may make a difference. I highly recommend you look at the other performance recommendations from the Page Speed tool, as it can give you loads of ideas for how to make your site faster and more responsive.

Notes on upgrading to WordPress 3.0 on 1and1

Tuesday, June 22nd, 2010

Normally I’d wait until at least the x.01 release of a new WordPress before upgrading. But this time I wanted to try the new WordPress soon after the final 3.0 version was out. I still waited a few days before installing it to let other people discover and fix any initial problems.

Problems and fixes

My wait paid off as a number of people who were using the same hosting company as me (1and1) found that the upgrade was failing with a ‘Fatal error: Allowed memory size of xxxxxxxx bytes exhausted’.

The fix for this problem is very simple – increase the allowed memory size, either by adding a php.ini , updating the wp-config.php, or for those who could wait a few days for an easier fix, by installing the Memory Bump plugin.

I installed Memory Bump, and went through all my usual WordPress backup steps, before attempting the install.

I pressed the Upgrade button, WordPress did something for about a minute and then I got this error message:

Downloading update from
Download failed.: Operation timed out after 60 seconds with 1023460
bytes received
Installation Failed

Not to panic though, this error is just saying that WordPress didn’t manage to download the new install package before its 60 second timeout. I pressed the button again, and this time it worked!

Downloading update from
Unpacking the update.
Verifying the unpacked files…
Installing the latest version…
Upgrading database…
WordPress upgraded successfully

New themes

The reason I wanted to upgrade as soon as possible was so that I could give reviewmylife a new theme. The old Kubrick theme was getting a bit old.

old reviewmylife blog

After a bit of searching and experimenting I found the News Magazine Theme 640 which I have now switched to.

new reviewmylife blog

One word of advice if you are switching themes – if you swap to a new one, and then back to the previous you might find that all your widgets have been set to inactive. You’ll have to re-add them again.

A second piece of advice is to keep any caching plugin you might have disabled whilst you play about with new themes and theme settings. This will make sure that you always see the latest generated pages, and not older cached ones. Don’t forget to turn the caching back on afterwards!

A later error

Whilst modifying one of my plugins I got this error on trying to activate it.

The plugin generated 3 characters of unexpected output during
activation. If you notice “headers already sent” messages,
problems with syndication feeds or other issues, try deactivating
or removing this plugin.

There are many possible causes, but in my case the problem was down to having opened the .php in Notepad and accidently saving it as UTF-8 instead of ANSI. I re-saved it as ANSI and it worked again.

Renaming table prefix on WordPress 2.9

Wednesday, May 19th, 2010

I wanted to rename the table prefix for this blog before upgrading to WordPress 3.0. I knew about the WordPress Table Prefix Rename Plugin which claimed to work for WordPress 2.x, but I couldn’t find anyone saying they had tried it specifically on WordPress 2.9.

wordpress table rename plugin

The only thing to do was to try it myself. As stated in the documentation this plugin doesn’t actually rename the tables, it copies the tables, and gives the copies your chosen prefix. It also modifies a few entries in the new tables which refer to the tables by name. Then it modifies the prefix entry in wp-config.php.

Before using it I looked through the PHP source code to make sure I was happy with what it was going to do. And of course I made full backups of my tables just in case it all went wrong.

I disabled the WP Super Cache plugin, and deleted the cache, to make sure that after the rename I could see the actual generated blog pages, rather than pages that had previously been cached by WP Super Cache.

I also opened the phpMyAdmin control panel that my web host (1and1) uses for managing the MySQL databases.

After installing and activating the plugin I went to its setting page, typed in my chosen table prefix, and pressed ‘Generate New Tables’. After 2-3 seconds it was done. I made a copy of the SQL statements that had been used (they get displayed on screen) for reference just in case I needed them later.

Then I pressed ‘Change $table_prefix’ button. This only took a second.

To check that everything had worked I logged out of WordPress and back in. I checked a few pages on the blog as well. And I checked wp-config.php using my FTP program to make sure it had been modified. It had all worked!

Using phpMyAdmin I checked that the new tables were the same size as the old ones (taking into account any overhead in the original tables).

I’d recommend you keep the old tables until you are sure that the new ones are working fine. Wait a few weeks – or even longer before deleting them if you have space. They don’t do any harm, and act as an extra backup of your data.

Table renaming tips

  • Read the plugin source so you know what it is going to do.
  • Backup your database tables, and verify that the backup is good.
  • Set aside enough time to restore your blog from backups in case it all goes wrong.
  • Keep your original tables if you have the space. More backups are good.

Tips for upgrading to WordPress 2.9 on 1and1

Thursday, December 24th, 2009

A few days ago I upgraded the my blog from WordPress 2.8.5 to 2.9. Here are some tips on what I did in case you run into any of the same issues that I did. That blog is hosted by 1and1 and some of the information may be specific to them.

This isn’t meant as a full upgrade guide – just a collection of tips that may help you.

First make sure you backup your data! There are some general wordpress backup tips on a post I did about a previous upgrade.

1. Export the SQL database

In the MySQL admin panel I selected these extra options: ‘Add DROP TABLE’ and ‘Complete inserts’, and then chose to save the file as a .gz (gzip) archive. If you need a free application to read .gz archives then I recommend 7-Zip.

Oneandone MySQL icon

2. Export the XML data

Export the XML post data from the WordPress admin panel (Tools->Export).

3. Zip and downloaded the blog files

Zip up the actual files on the server. On 1and1 the easiest way to do this is to logon to your admin panel, go to the Webspace Explorer, right-click on the directory and select ‘zip’.

You can then right-click on the zip file and choose download to copy it down to your computer.

4. Verify the data

I verified that the exported SQL data, XLM and .zip files were valid. The easiest way to verify the SQL and XLM data is to look at it in a text viewer such as NoteTab Light and make sure that the data at the end of the file is valid. Sometime a download can silently fail and you can end up with truncated data. If you try to restore the data from a truncated file then the restore will fail.

Verify the .gz file by making sure it will open in 7-Zip.

Click on the upgrade button

I finally was ready to click on the upgrade button. I clicked on it and a second or two later I got the message:

‘The update cannot be installed because WordPress 2.9 requires MySQL version 4.1.2 or higher. You are running version 4.0.27’

How I got around it

The partial answer is contained in the post here. However I’ll add a few bits of information on what I did differently.

I created a new MySQL 5.0 database from the MySQL admin panel. On the old 1and1 business hosting package I think you can create two MySQL databases (or up to 10 on the newer business hosting package) so you don’t need to delete the existing one first. Don’t delete it – you may need it if everything goes wrong with the upgrade!

I didn’t import the data by using the XML backup. I imported the data into the new MySQL 5.0 database from the gzipped SQL archive that I’d created in step 1 above.

You can import the SQL data from the MySQL admin panel by going to the tab to execute SQL commands, and then selecting the .gz file. Importing the SQL file through a .gz file gets around the 2MB size limit in the MySQL admin panel.

Importing from the .gz file rather than the .XML will import all your database data, and plugin settings, whereas if you do it from the .XML file you may have to manually re-enter various settings into your blog.

In your wp-config.php you will have to ensure that the DB_NAME, DB_USER, DB_PASSWORD and DB_HOST have been updated with the settings of your new MySQL 5.0 database.

Upload the wp-config.php file and if everything has gone right your blog should still be working and look exactly the same as before. Your blog will be using the old version of WordPress but will be accessing the data from the new MySQL 5.0 database.

You should now be able to click on the upgrade button and the blog should upgrade in less than 5 seconds.

This worked fine for me on 1and1. If you have loads of plugins or a heavily customised theme you may find more problems. If this is the case you can try deactivating plugins, or switch to the default theme.

If you really can’t get things to work you should be able to roll back to your pre-2.9 WordPress blog by restoring the files that you zipped in step 3 above. You MySQL 4.0 database should still be there (as long as you didn’t delete it).

Upgrading WordPress can often be a pain but at least having upgraded the SQL database from 4.0 to 5.0 should avoid more problems in the future. And now with WordPress 2.9 you can look forward to batch updating your plugins rather than doing them one at a time!

Upgrade WordPress to 2.8.1 on 1and1

Tuesday, July 14th, 2009

In the bad old days upgrading anything WordPress related (plugins, themes, or WordPress itself) would at best involve manually downloading a zip, extracting it locally and then using FTP to upload the changes to your web server. At worst it could require manually editing files, and making database changes.

In February last year I wrote about how cool it was that the All in One SEO Plugin had a one-click upgrade facility. Updating plugins had always been a big pain, especially when you have a blog with many plugins (this one has about 10) so it was great when WordPress introduced one-click plugin upgrade support. Although plugins could now be upgraded with a single click, upgrading WordPress itself was still a manual task.

In WordPress 2.7 they introduced one click upgrade support of WordPress itself. When 2.8.0 was released a message at the top of my blog console prompted me to do a one-click upgrade. I decided to wait. Upgrading to a x.x.0 release can be risky. These are major updates and often have many bugs. Waiting until the x.x.1 release can be safer unless there is an urgent reason to upgrade (such as a critical security update).

Another reason for delaying a WordPress upgrade is that it can take a while for the plugins that you use to be updated to be compatible with the new version. Sometime no changes are needed, but when WordPress update their database structure, plugins are particularly vulnerable to breaking.

Even though you can now upgrade from 2.7.x to 2.8.x with one click, upgrading is never that simple. With each upgrade there is a chance that you will completely trash your blog.

Firstly make sure you have plenty of time. If it goes well it shouldn’t take too long. What you don’t want to do is for it to go badly wrong and end up with your blog trashed, just before you have to leave for an urgent appointment.

You MUST do your backups before upgrading. Before backing up I make sure all the plugins are up-to-date and I delete any comment spam so this isn’t backed-up.

I always do three different backups.

  1. File backup – I FTP all the blog files down to my computer.
  2. XML export – Export all the blog information as an XML file using the Tools->Export option.
  3. MySQL database backup – A full MySQL database backup using the backup instructions from the official WordPress website. On 1and1 you select the MySQL admin panel using the highlighted button shown below.

Oneandone MySQL icon

After backing up I verify that the backups look correct. I generally diff the XML and database dump to my previous backup using the Beyond Compare tool. The main thing to check is that the backups haven’t been truncated due to a failed download. If the files are much smaller than previous backups then you may have a problem.

I’d read that in order for the upgrade to work on 1and1 you need to ensure that your website is processing .php files using PHP5 rather than PHP4. To ensure this you must have the below line in your .htaccess file in the root of your blog.

AddType x-mapp-php5 .php

After all this there was just one thing left – to press the ‘Upgrade’ button.

I pressed it and held my breath. Some messages appeared on the screen and about 10-15 seconds later it said the upgrade had succeeded. At first I thought something must have gone wrong, as it was so quick. I logged back into the blog and saw that it had worked!

The only problem that I found was due to me having made some changes to the default theme. These changes had been overwritten. Luckily due to the file backup that I had made by FTP I was able to restore them in a few minutes. The lesson to learn here is not to change the default theme. You should copy it to a new directory and only change the copied version. If you want to keep any updates to the default theme in sync with your modified theme you may have to manually merge them in, but at least you won’t lose your theme updates.

Congratulations to the implementers of this feature in WordPress. It is much appreciated by me :)

Custom error pages on 1and1 when HTML files are set as PHP types

Monday, May 26th, 2008

A long time ago I set up custom error pages on my 1&1 hosted websites. However recently I noticed that they had stopped working. When a 404 error occured, instead of redirecting to my error page I got an advert filled parking page.

1and1 error page

I re-checked their instructions for setting up the error pages on their FAQ and I was pretty sure that I was setting the pages up correctly.

After spending over an hour trying to figure out what was going wrong I stumbled on the ‘Empty Parking Pages’ link on the Domain Overview in their Administration control panel. You can see the position of this link in the red box.

1and1 admin page

On this page is the option to turn off their ‘Empty Parking Pages’. I turned this option off – it then took a few minutes for the change to be visible on my website.

1and1 empty pages parking

Part of the message says:

When using this service, a page from our webserver will be displayed instead. Unless, of course, you have set up your own error message.

Now instead of getting the advert filled parking page I got a plain:

Error 404 – Not found
Your browser can’t find the document corresponding to the URL you typed in.

It is better than before but it is still not my error message!

It seemed the only way I could get correctly working error files is to create files with the following file names in your site’s root directory – ‘error400.html’, ‘error403.html’, ‘error404.html’ and ‘error500.html’. No entry in the .htaccess file is needed – 1&1 automatically picks these files up as your error pages.

So why weren’t the ErrorDocument lines in my .htaccess working?

In my .htaccess file I also have the following line:
AddType x-mapp-php4 .html .htm

This line allows PHP code to be processed from .htm and .html files. If I remove this line then my ErrorDocument lines start working. It therefore seems that 1and1 have configured their servers so that you can only errors generated when you try to access static pages will cause the ErrorDocument directive to be used. Usually .html and .htm are static, however my AddType line in the .htaccess changed them into dynamic pages.

I removed .html from the AddType line. After doing this the ErrorDocument worked for .html files but not for .htm.

After all this I have deduced the following:

  1. If you want to get rid of the advert filled parking pages you need to use the control panel.
  2. If you configure your 1&1 .htaccess file to allow PHP in .htm and .html then the ErrorDocument line won’t work for any missing .htm or .html files. However the ErrorDocument will work for non-PHP files types.
  3. The ErrorDocument directive will never work for .php file types as these are always registered as being PHP types.
  4. The only way to get working error files for all types of errors is to create ‘error400.html’, ‘error403.html’, ‘error404.html’ and ‘error500.html’ files.

Final tip

In the 1&1 FAQ on creating error pages they give three suggestion for creating custom error pages:

  1. Using ErrorDocument in .htaccess (which only works for static document types).
  2. Adding the errorXXX.html error pages (which does work for all document types).
  3. Adding the below code to your .htaccess.

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule (.*) /errordocument.html

I would suggest that you don’t add this to your .htaccess! This redirects any 404 ‘not found’ errors to the errordocument.html webpage. This causes a 200 error code to be returned rather than a 404 error code. This is a bad idea as it could cause search engines to end up indexing all the error pages on your website.

Setting up a WordPress blog on 1and1

Sunday, August 5th, 2007

Having decided to start a blog I had two main options for how to do it. Either create a blog using one of the many blog hosting sites, or host it myself on my own 1 and 1 web space. Hosting it myself is clearly the most flexible option, and for a techy like me the most fun. I did a bit of research into different blogging software and WordPress to me looks good enough for me.

I was initially a bit worried about the amount of MySQL database space that is needed for blog software. 1&1 databases are limited to 100mb and I wasn’t sure how much space WordPress would need. At work I manage a 5db database with the largest table having over 100 million rows so I’m well aware that databases can get big! Fortunately it seems that WordPress uses space very efficiently and even very large blogs only need a few megabytes.

WordPress comes with a load of documentation, but I did most of my setup by following the instructions on which has some good instructions specifically tailored for people on 1&1.

I’ve left the configuration pretty much at the default settings for now but I did add to the ‘Options->Writing->Update Services’ box so that Google Blog Search is notified for each update.