Tips and Tricks
Written by Sean Valant
Saturday, February 23rd, 2013
The “Snappy’s ProTips” blog post series is an on-going effort to raise awareness regarding some of the most common support requests that we receive via ticket. By and large, all issues covered in this series can be resolved quickly and easily by utilizing information contained within the HostGator KnowledgeBase. As such, these issues can be addressed and resolved inrealtime, without necessarily needing to wait for a ticket response from a System Administrator. The issues covered in this blog post series account for hundreds of support tickets each week.
We receive many support requests each week regarding PHP, specifically what PHP modules are supported and how to enable specific version of PHP on our shared servers.
Typing “php” into the search field on the KB will result in an auto-suggestion for the article “PHP Modules”: https://support.hostgator.com/articles/hosting-guide/hardware-software/php-modules
The above link is a comprehensive list of every PHP module that is currently installed on our Linux and Windows shared servers. There is a very small number of caveats and exceptions, for example Imagic and Magicwand are currently only available on Linux servers and Oauth is installed, but must be enabled prior to use by adding the following line to the php.ini file: oauth:extension=oauth.so
As a rule, if the module is not on the list, then it is not compatible, or not allowed, on our shared environment. VPS and Dedicated servers are significantly less restrictive when it comes to requesting/applying PHP modules.
The next most common support request involving PHP is how to enable a specific version, usually PHP 5.3, on shared servers. As with every issue we’ll be addressing, full information is contained in the following KB article: https://support.hostgator.com/articles/hosting-guide/hardware-software/php-5-3
In a nutshell, this can be accomplished via a very simple addition to the .htaccess file:
# Use PHP 5.3
AddType application/x-httpd-php53 .php
It is very important to read and understand the associated KB article, because this can cause unexpected results relative to backwards compatibility issues with scripts; older PHP coding may not be compatible with newer versions of PHP.
If you are unfamiliar with the editing of an .htaccess files, the above KB article contains another link explaining that process. I cannot be stressed enough that you should make these modifications with care, and be sure to read the entire KB article before proceeding, in order to gather all the relative information to ensure you are as informed as possible regarding the changes you will be making. As always, you should create a full backup before making any changes of this nature to your account.
When in doubt, do join us in LiveChat so that we may assist you in realtime. If you are ultimately performing an action that will require a support ticket to receive assistance from a System Administrator, then we’ll certainly create that ticket for you via LiveChat.
Please leave us a comment if you have any topic that you would like to be addresses via the on-going “Snappy’s ProTips” blog series.
Written by Taylor Hawes
Thursday, February 21st, 2013
As a webmaster, you know that it isn’t enough for your website to be “pretty” – it needs to be effective as well. Whether you’ve set up your site to sell products, collect leads or simply promote a certain viewpoint, your primary focus as a website owner must be to make sure that your site performs its designated function as efficiently as possible.
To do that, you need split testing – as in, the process of randomly serving up different page variations to viewers in order to conclusively determine which version helps achieve your target metrics. Here’s what you need to know about implementing this critical process on your own site:
Step #1 – Select a target variable
To get started with split testing, you’ll first need to select a variable that will be the focus of your test. This process is best explained with an example…
Suppose you have a page on your site that sells a digital download product. You’ve seen an unfortunately high bounce rate from visitors on this page, so you decide to use split testing to determine what changes can be made to keep visitors on the page longer and increase the resulting number of sales. For this reason, you decide to set up a split test that pits two different headline versions against each other, as this is the first element visitors to the page will encounter.
To conduct this test, you’d create two separate versions of your sales page – each one featuring a different headline. Once set up, your split test would direct visitors to one version or the other randomly, enabling you to determine which headline variant results in the most sales.
This specific example utilizes a type of split testing known as A/B testing, which takes its name from the fact that you’re comparing one page version against another in which a single variable has been changed. If you’d changed multiple variables on your test sales page (for example, your headline, your call-to-action and your “Buy Now” button color), you wouldn’t be able to conclusively determine which single action led to increased conversions.
A more advanced type of split testing – multivariate testing – is available if you’d like to be able to compare multiple variables at once while still generating meaningful data. However, implementing this type of test correctly is more complicated, which makes the process better suited to advanced webmasters, rather than beginning split testers.
Assuming you’re going ahead with the A/B testing protocol, you’ll want to identify your target variable before moving on to set up your test in Step #2. Besides your page’s headline, a few other elements you can test include:
- The placement and selection of images on your site
- The specific wording used in your calls-to-action
- The price of your products
- The location and wording used on your email list opt-in box
- The shape, color and location of your “Add to Cart” buttons
Really, the possibilities are endless when it comes to choosing a test variable. For your first test, try to select a variable that stands to make the biggest possible difference in your site’s performance (for example, test your headline text, rather than the font you use in your 3rd paragraph). Then, create the test version of your split test page and move on to the next step in this process.
Step #2 – Use split testing programs to launch your test
By far, the most popular program used to run split tests online today is Google Analytics’ “Content Experiments” (formerly known as the Google “Website Optimizer”). The program is free and incredibly simple to use, making it a great place for beginning marketers to start.
To run an A/B split test using Content Experiments, you’ll need three pieces of information:
- The URL of your original page (for example, sales-page.html)
- The URL of your test variation (sales-page-2.html)
- The Google Analytics goal you’ll use to determine which page variation results in a conversion.
Once you have all three of these items identified and setup, head to the “Content -> Experiments” section of your Google Analytics dashboard and begin by entering the URL of your original page into the prompt. Click “Start Experimenting” and you’ll be prompted to enter a few different pieces of information, including your test URLs, goal selection and a few other testing parameters.
Finally, after this information has been entered and verified, you’ll be provided with a new version of your Google Analytics tracking code that must be installed on all the different pages that will be involved in your test. If you’re technically savvy, you can add this tracking code on your own and then use Google’s built-in tools to verify that it’s been added correctly. If not, Google Analytics provides a helpful set of instructions that can be sent to your site’s web developer.
Step #3 – Identify a winner and launch a new test
After completing the verification process and launching your test, you’ll see data start to flow in to your Google Analytics dashboard as visitors arrive on your site and interact with your pages. Eventually, Google Analytics will report a “winner” for your experiment, based on the confidence threshold you set during the setup process (the default is 95% confidence).
Keep in mind that it’s very important to wait until this measure of statistical significance has been reached, as picking a winner after only a handful of goal completions doesn’t provide you with any meaningful data. If your site is young and not yet receiving many visitors, it can take awhile to reach your requested confidence threshold, but be patient! Making decisions off of incomplete data is no better than failing to split test in the first place.
Once a winner has been chosen in your test, make any necessary changes to your live site based on your results and then launch another test immediately. The most effective websites rely on a program of continual split testing to make much-needed improvements. Don’t short-change yourself by running one test and then quitting.
That, in a nutshell, is the A/B split testing process, as well as how it can be used to make your website more effective than ever. If you need further information, check out the Google Analytics “Overview of Content Experiments” help section for more detailed instructions on using this program to improve your website results.
Written by Sean Valant
Friday, February 15th, 2013
We’ve been doing some audits and running some numbers on our ticket queues lately. What we’ve found is that there are a lot of recurring issues that are actually very basic in nature, but that our Customers either aren’t able to find the answers to themselves or they don’t realize that the answers are actually just a quick KnowledgeBase search away.
So, we’re introducing our “Snappy’s ProTips” blog series. The issues we will be discussing herein account for literally hundreds of support requests each week. Our hope is that, via this series, we can raise awareness as to the resolution of common issues and facilitate not only a higher level of learning for our Customers, but also a faster response time on more involved issues by clearing out some of these more basic requests.
We’re always happy to assist with anything, however it stands to reason that for these more basic issues that you’d just assume not have to wait for a response via ticket from us when you can truly (and much more efficiently) handle it yourself in real time.
One of the most fundamental issues that we most often encounter requests for via ticket is how to change the primary domain on a hosting account. For VPS or Dedicated Servers we actually will need to have a ticket generated in order for us to complete this request on your behalf. However, any Shared or Reseller account can have its primary domain changed very easily from within the billing tool.
This process is covered quite thoroughly at the following URL, from our KnowledgeBase:
It cannot be stressed enough that you should always create a full backup before making any changes of this nature, and keep in mind that the full information is in the KB article above; this blog post is not intended to be a definitive guide to this process.
It’s very important to understand that, due to the nature of cPanel, the contents of the public_html folder will always be displayed as the web site of the Primary Domain on the account. Let’s illustrate this point by using the following example:
Your Primary Domain is pirates-are-awesome.com and you have an addon domain called ninjas-are-awesome.com that you would prefer be your Primary Domain. You can easily log into your billing account and follow the directions as stated in the KB page linked above in order to change your Primary Domain to ninjas-are-awesome.com. If you stop there and take no further action, then what will happen is that anyone who browses to ninjas-are-awesome.com will actually see the content of pirates-are-awesome.com, because it’s the content of the pirate site that actually resides in the public_html directory and, as we now know, cPanel will display the contents of public_html as the website of the Primary Domain.
Any time you change your Primary Domain, you must then ensure that the files for the relative sites are also then relocated appropriately.
In keeping with our above example, you would now need to move some files around. First, you would need to add the old Primary Domain as an Addon Domain within cPanel, which would then result in the creation of a subfolder within public_html that would then need to house the files for pirates-are-awesome.com. Conversely, it is also necessary to relocate the contents of the subfolder for ninjas-are-awesome.com (since it was formerly an Addon Domain, there will be a subfolder within public_html that contains the files for that website) directly into public_html. In order to not mix up any files, you will want to perform these moves in the same order we’ve presented them: create the Addon Domain, move the filed from public_html into that folder, then move the contents from the subfolder for the former Addon Domain directly into public_html, thereby causing the files of the Primary Domain be exist directly within public_html while the files for the new Addon Domain are now located within the appropriate subfolder of public_html.
As you see this is a two-part process: change the Primary Domain logically from within the billing account, and then physically move the files of the website to (and/or from) the appropriate folder(s).
It sounds more complicated than it actually is, but keep in mind that there can be extenuating circumstances depending on the complexity or nature of the website in question. When in doubt, please do not hesitate to reach out to us for assistance. In cases where there are no website files to actually move though, this is an incredibly fast and straight-forward process.
If you have any questions about this process, please leave us a comment and we’ll be happy to clarify. Additionally, if you have any basic technical issues that you would like addressed as part of our “Snappy’s ProTips” series, please leave us a comment as well.
Written by Sean Valant
Tuesday, January 22nd, 2013
What is WHOIS? WHOIS, in a literal sense, is a protocol used to query databases that store registration information relative to Internet resources. Sounds complicated, but for our purposes at this time, WHOIS is simply a means of finding out who owns a given domain name. There are countless websites that allow you to run a WHOIS search; any domain registrar, for starters. You can essentially choose at random from a quick Google search for WHOIS.
When you do perform a WHOIS search on a domain, you find all sorts of information about the registrant of the given domain. In a nutshell, you’ll see all of the publicly available information relative to the given domain. Here’s the truncated results from a WHOIS search for HostGator.com, which is a perfect example:
We see when the domain was created and when the current registration period expires. We also see the nameservers to which the domain is pointed. The most important piece though is the name, address and phone number of the registrant. The information shown here for HostGator.com is essentially all publicly available information already, so it’s really a no harm and no foul situation.
However, when any given citizen registers a domain name they are putting their full name, address and phone number out there and attaching it to the various domain names they may have registered. If you are unaware of this circumstance and have currently registered domains, you might want to WHOIS your domains and see what you see. Do you necessarily want your personal contact information out there, attached to your domains and viewable by anyone?
It may occur to you to use false or otherwise incomplete information when registering a domain in order to maintain your privacy, however the WHOIS information legally and contractually determines who has control of the domain. For more information regarding this, please see this helpful link from our KnowledgeBase.
So, here is the situation most of us find ourselves in: we must use valid information on our domain registrations, but we don’t want that information freely available to the public? This is where domain privacy, or WHOIS protection comes in.
HostGator offers WHOIS protection on any domain we register. Domains registered via eNom utilize a service called ID Protect, while LaunchPad registered domains use Privacy Protection. The functionality for both is the same; protecting your personal information from being displayed publically within WHOIS searches.
Any time you register a domain via HostGator, you have the option of enabling WHOIS privacy. Conversely, if you have purchased domains in the past, you can contact us at any time to have this service added to your domains. Privacy is serious business in today’s world and we are happy to be able to offer this service. HostGator recommends WHOIS privacy for all of your domains.