Chapter 3

Finding and Setting Up a Web Host

IN THIS CHAPTER

check Understanding web hosting providers

check Examining the various choices for hosting your site

check Choosing the host that’s right for you

check Looking around your new web home

check Getting your site files to your web host

You will end up with better software by releasing as early as practically possible, and then spending the rest of your time iterating rapidly based on real-world feedback. So trust me on this one: Even if version 1 sucks, ship it anyway.

— JEFF ATTWOOD

You build your web pages from the comfort of your Mac or PC, and if you’ve chosen your text editor well (as I describe in Book 1, Chapter 2), then you can even use your computer to preview how your web pages will look in a browser.

That’s fine and dandy, but I think you’ll agree that the whole point of building a web page is to, you know, put it on the web! First, you need to subject your code to the wilds of the wider web to make sure it works out there. Even if it seems to be running like a champ on your local server, you can’t give it the seal of approval until you’ve proven that it runs champlike on a remote server. Second, once your code is ready, then the only way the public can appreciate your handiwork is to get it out where they can see it.

Whether you’re testing or shipping your code, you need somewhere to put it, and that’s what this chapter is about. Here you explore the wide and sometimes wacky world of web hosts. You delve into what they offer, investigate ways to choose a good one, and then take a tour of your web home away from home.

Understanding Web Hosting Providers

A common question posed by web development newcomers is “Where the heck do I put my web page when it’s done?” If you’ve asked that question, you’re doing okay because it means you’re clued in to something crucial: Just because you’ve created a web page and you have an Internet connection doesn’t mean your site is automatically a part of the web.

After all, people on the web have no way of getting to your computer. Even if you’re working with a local web development environment (which I discuss in Book 1, Chapter 2), you’re working in splendid isolation because no one either on your network or on the Internet can access that environment.

In other words, your computer isn’t set up to hand out documents (such as web pages) to remote visitors who ask for them. Computers that can do this are called servers (because they “serve” stuff out to the web), and computers that specialize in distributing web pages are called web servers. So your web page isn’t on the web until you store it on a remote web server. Because this computer is, in effect, playing “host” to your pages, such machines are also called web hosts. Companies that run these web hosts are called web hosting providers.

Now, just how do you go about finding a web host? Well, the answer to that depends on a bunch of factors, including the type of site you have, how you get connected to the Internet in the first place, and how much money (if any) you’re willing to fork out for the privilege. In the end, you have three choices:

  • Your existing Internet provider
  • A free hosting provider
  • A commercial hosting provider

Using your existing Internet provider

If you access the Internet via a corporate or educational network, your institution might have its own web server you can use. If you get online via an Internet service provider (ISP), phone or email its customer service department to ask whether the company has a web server available. Almost all ISPs provide space so their customers can put up personal pages free of charge.

Finding a free hosting provider

If cash is in short supply, a few hosting providers will bring your website in from the cold out of the goodness of their hearts. In some cases, these services are open only to specific groups such as students, artists, nonprofit organizations, and so on. However, plenty of providers put up personal sites free of charge.

What’s the catch? Well, there are almost always restrictions both on how much data you can store and on the type of data you can store (no ads, no dirty pictures, and so on). You might also be required to display some kind of “banner” advertisement for the hosting provider on your pages.

Signing up with a commercial hosting provider

For personal and business-related websites, many web artisans end up renting a chunk of a web server from a commercial hosting provider. You normally hand over a setup fee to get your account going and then you’re looking at a monthly fee.

Why shell out all that dough when there are so many free sites lying around? Because, as with most things in life, you get what you pay for. By paying for your host, you generally get more features, better service, and fewer annoyances (such as the ads that some free sites have to display).

A Buyer’s Guide to Web Hosting

Unfortunately, choosing a web host isn’t as straightforward as you might like it to be. For one thing, hundreds of hosts are out there clamoring for your business; for another, the pitches and come-ons your average web host employs are strewn with jargon and technical terms. I can’t help reduce the number of web hosts, but I can help you understand what those hosts are yammering on about. Here’s a list of the terms you’re most likely to come across when researching web hosts:

  • Storage space: Refers to the amount of room allotted to you on the host’s web server to store your files. The amount of acreage you get determines the amount of data you can store. For example, if you get a 1MB (1 megabyte) limit, you can’t store more than 1MB worth of files on the server. HTML files don’t take up much real estate, but large graphics sure do, so you need to watch your limit. For example, you could probably store about 200 pages in 1MB of storage (assuming about 5KB per page), but only about 20 images (assuming about 50KB per image). Generally speaking, the more you pay for a host, the more storage space you get.

  • Bandwidth: A measure of how much of your data the server serves. For example, suppose the HTML file for your page is 1KB (1 kilobyte) and the graphics associated with the page consume 9KB. If someone accesses your page, the server ships out a total of 10KB; if ten people access the page (either at the same time or over a period of time), the total bandwidth is 100KB. Most hosts give you a bandwidth limit (or “cap”), which is most often a certain number of megabytes or gigabytes per month. (A gigabyte is equal to about 1,000 megabytes.) Again, the more you pay, the greater the bandwidth you get.

    warning If you exceed your bandwidth limit, users will usually still be able to get to your pages (although some hosts shut down access to an offending site). However, almost all web hosts charge you an extra fee for exceeding your bandwidth, so check this out before signing up. The usual penalty is a set fee per every megabyte or gigabyte over your cap.

  • Domain name: A general Internet address, such as wiley.com or whitehouse.gov. They tend to be easier to remember than the long-winded addresses most web hosts supply you by default, so they’re a popular feature. Two types of domain names are available:

    • A regular domain name (such as yourdomain.com or yourdomain.org)
    • A subdomain name (such as yourdomain.webhostdomain.com)

    To get a regular domain, you either need to use one of the many domain registration services such as GoDaddy or Register.com. A more convenient route is to choose a web hosting provider that will do this for you. Either way, it will usually cost you $35 per year (although some hosts offer cheap domains as a “loss leader” and recoup their costs with hosting fees; also, discount domain registrars such as GoDaddy offer domains for as little as $9.99 per year). If you go the direct route, almost all web hosts will host your domain, which means that people who use your domain name will get directed to your website on the host’s web server. For this to work, you must tweak the domain settings on the registrar. This usually involves changing the DNS servers associated with the domain so that they point at the web host’s domain name servers. Your web host will give you instructions on how to do this.

    With a subdomain name, “webhostdomain.com” is the domain name of the web hosting company, and it simply tacks on whatever name you want to the beginning. Many web hosts will provide you with this type of domain, often for free.

  • Email addresses: Most hosts offer you one or more email addresses along with your web space. The more you pay, the more mailboxes you get. Some hosts offer email forwarding, which enables you to have messages that are sent to your web host address rerouted to some other email address.
  • Shared server: If the host offers a shared server (or virtual server), it means that you’ll be sharing the server with other websites — dozens or even hundreds of them. The web host takes care of all the highly technical server management chores, so all you have to do is maintain your site. This is by far the best (and cheapest) choice for individuals or small business types.
  • Dedicated server: You get your very own server computer on the host. That may sound like a good thing, but it’s usually up to you to manage the server, which can be a dauntingly technical task. Also, dedicated servers are much more expensive than shared servers.
  • Operating system: The operating system on the web server. You usually have two choices: Unix (or Linux) and Windows Server. Unix systems have the reputation of being very reliable and fast, even under heavy traffic loads, so they’re usually the best choice for a shared server. Windows systems are a better choice for dedicated servers because they’re easier to administer than their Unix brethren. Note, too, that Unix servers are case sensitive in terms of file and directory names, while Windows servers are not.
  • Databases: The number of databases you get to create with your account. Unix systems usually offer MySQL databases, whereas Windows servers offer SQL Server databases.
  • Administration interface: This is the host app that you use to perform tasks on the server, such as uploading files or creating users. Many hosts offer the excellent cPanel interface, and most Unix-based systems offer the phpMyAdmin app for managing your MySQL data.
  • Ad requirements: A few free web hosts require you to display some type of advertising on your pages. This could be a banner ad across the top of the page, a “pop-up” ad that appears each time a person accesses your pages, or a “watermark” ad, usually a semitransparent logo that hovers over your page. Fortunately, free hosts that insist on ads are rare these days.
  • Uptime: The percentage of time the host’s server is up and serving. There’s no such thing as 100 percent uptime because all servers require maintenance and upgrades at some point. However, the best hosts have uptime numbers over 99 percent. (If a host doesn’t advertise its uptime, it’s probably because it’s very low. Be sure to ask before committing yourself.)
  • Tech support: If you have problems setting up or accessing your site, you want to know that help — in the form of tech support — is just around the corner. The best hosts offer 24/7 tech support, which means you can contact the company — either by phone or email — 24 hours a day, 7 days a week.
  • FTP support: You usually use the Internet’s FTP service to transfer your files from your computer to the web host. If a host offers FTP access (some hosts have their own method for transferring files), be sure you can use it any time you want and there are no restrictions on the amount of data you can transfer at one time.
  • Website statistics: Tell you things such as how many people have visited your site, which pages are the most popular, how much bandwidth you’re consuming, which browsers and browser versions surfers are using, and more. Most decent hosts offer a ready-made stats package, but the best ones also give you access to the “raw” log files so you can play with the data yourself.
  • Ecommerce: Some hosts offer a service that lets you set up a web “store” so you can sell stuff on your site. That service usually includes a “shopping script,” access to credit card authorization and other payment systems, and the ability to set up a secure connection. You usually get this only in the more expensive hosting packages, and you’ll most often have to pay a setup fee to get your store built.
  • Scalability: The host is able to modify your site’s features as required. For example, if your site becomes very popular, you might need to increase your bandwidth limit. If the host is scalable, it can easily change your limit (or any other feature of your site).

Finding a Web Host

Okay, you’re ready to start researching the hosts to find one that suits your web style. As I mention earlier, there are hundreds, perhaps even thousands, of hosts, so how is a body supposed to whittle them down to some kind of short list? Here are some ideas:

  • Ask your friends and colleagues. The best way to find a good host is that old standby, word of mouth. If someone you trust says a host is good, chances are you won’t be disappointed. This is assuming you and your pal have similar hosting needs. If you want a full-blown ecommerce site, don’t solicit recommendations from someone who has only a humble home page.
  • Solicit host reviews from experts. Ask existing webmasters and other people “in the know” about which hosts they recommend or have heard good things about. A good place to find such experts is Web Hosting Talk (www.webhostingtalk.com), a collection of forums related to web hosting.
  • Contact web host customers. Visit sites that use a particular web host, and send an email message to the webmaster asking what she thinks of the host’s service.
  • Peruse the lists of web hosts. A number of sites track and compare web hosts, so they’re an easy way to get in a lot of research. Careful, though, because there are a lot of sketchy lists out there that are only trying to make a buck by getting you to click ads. Here are some reputable places to start:

Finding Your Way around Your New Web Home

After you sign up with a web hosting provider and your account is established, the web administrator creates two things for you: a directory on the server you can use to store your website files, and your very own web address. (This is also true if you’re using a web server associated with your corporate or school network.) The directory — which is known in the biz as your root directory — usually takes one of the following forms:

/yourname/

/home/yourname/

/yourname/public_html/

In each case, yourname is the login name (or username) the provider assigns to you, or it may be your domain name (with or without the .com part). Remember, your root directory is a slice of the host's web server, and this slice is yours to monkey around with as you see fit. This usually means you can do all or most of the following to the root:

  • Add files to the directory.
  • Add subdirectories to the directory.
  • Move or copy files from one directory to another.
  • Rename files or directories.
  • Delete files from the directory.

Your web address normally takes one of the following shapes:

http://provider/yourname/

http://yourname.provider/

http://www.yourname.com/

Here, provider is the host name of your provider (for example, www.hostcompany.com or just hostcompany.com), and yourname is your login name or domain name. Here are some examples:

http://www.hostcompany.com/mywebsite/

http://mywebsite.hostcompany.com/

http://www.mywebsite.com/

Your directory and your web address

There's a direct and important relationship between your server directory and your address. That is, your address actually “points to” your directory and enables other people to view the files you store in that directory. For example, suppose I decide to store a file named thingamajig.html in my directory and my main address is http://mywebsite.hostcompany.com/. This means someone else can view that page by typing the following URL into a web browser:

http://mywebsite.hostcompany.com/thingamajig.html

Similarly, suppose I create a subdirectory named stuff and use it to store a file named index.html. A surfer can view that file by convincing a web browser to head for the following URL:

http://mywebsite.hostcompany.com/stuff/index.html

In other words, folks can surf to your files and directories by strategically tacking on the appropriate filenames and directory names after your main web address.

Making your hard disk mirror your web home

As a web developer, one of the key ways to keep your projects organized is to set up your directories on your computer, and then mirror those directories on your web host. Believe me, this will make your uploading duties immeasurably easier.

remember Moving a file from your computer to a remote location (such as your web host's server) is known in the file transfer trade as uploading.

This process begins at the root. On the web host, you already have a root directory assigned to you by the hosting provider, so now you need to designate a folder on your computer to be the root mirror. If you’re using the XAMPP web development environment (see Book 1, Chapter 2), then the XAMPP installation’s htdocs subfolder is perfect as your local root. Otherwise, choose or create a folder on your computer to use as the local root.

What you do from here depends on the number of web development projects you’re going to build, and the number of files in each project:

  • A single web development project consisting of just a few files: In this case, just put all the files into the root directory.
  • A single web development project consisting of many files: The more likely scenario for a typical web development project is to have multiple HTML, CSS, JavaScript, and PHP files, plus lots of ancillary files such as images and fonts. Although it’s okay to place all your HTML files in the root directory, do yourself a favor and organize all your other files into subfolders by file type: a css subfolder for CSS files, a js subfolder for JavaScript files, and so on.
  • Multiple web development projects: As a web developer, you'll almost certainly create tons of web projects, so it’s crucial to organize them. The ideal way to do that is to create a separate root subdirectory for each project. Then within each of these subdirectories, you can create sub-subdirectories for file types such as CSS, JavaScript, images, and so on.

To help you see why mirroring your local and remote directory structures is so useful, suppose you set up a subfolder on your computer named graphics that you use to store your image files. To insert into your page a file named mydog.jpg from that folder, you'd use the following reference:

graphics/mydog.jpg

When you send your HTML file to the server and you then display the file in a browser, it looks for mydog.jpg in the graphics subdirectory. If you don't have such a subdirectory — either you didn’t create it or you used a different name, such as images — the browser won’t find mydog.jpg and your image won't show. In other words, if you match the subdirectories on your web server with the subfolders on your computer, your page will work properly without modifications both at home and on the web.

warning One common faux pas beginning web developers make is to include the local drive and all the folder names when referencing a file. Here’s an example:

C:xampphtdocsgraphicsmydog.jpg

This image will show up just fine when it’s viewed from your computer, but it will fail miserably when you upload it to the server and view it on the web. That’s because the C:xampphtdocs part exists only on your computer.

warning The Unix (or Linux) computers that play host to the vast majority of web servers are downright finicky when it comes to the uppercase and lowercase letters used in file and directory names. It’s crucial that you check the file references in your code to be sure the file and directory names you use match the combination of uppercase and lowercase letters used on your server. For example, suppose you have a CSS file on your server that’s named styles.css. If your HTML references that file as, say, STYLES.CSS, the server won't find the file and your styles won’t get applied.

Uploading your site files

Once your web page or site is ready for its debut, it’s time to get your files to your host’s web server. If the server is on your company or school network, you send the files over the network to the directory set up by your system administrator. Otherwise, you upload the files to the root directory created for you on the hosting provider’s web server.

How you go about uploading your site files depends on the web host, but here are the four most common scenarios:

  • Use an FTP program. It’s a rare web host that doesn’t offer support for the File Transfer Protocol (FTP, for short), which is the Internet’s most popular method for transfer files from here to there. To use FTP, you usually need to get a piece of software called an FTP client, which enables you to connect to your web host’s FTP server (your host can provide you with instructions for this) and offers an interface for standard file tasks, such as navigating and creating folders, uploading the files, deleting and renaming files, and so on. Popular Windows clients are CuteFTP (www.globalscape.com/cuteftp) and Cyberduck (https://cyberduck.io). For the Mac, try Transmit (https://panic.com/transmit) or FileZilla (https://filezilla-project.org).
  • Use your text editor’s file upload feature. Some text editors come with an FTP client built-in, so you can edit a file and then immediately upload it with a single command. The Coda text editor (https://panic.com/coda) supports this too-handy-for-words feature.
  • Use the File Manager feature of cPanel. I mention earlier that lots of web hosts offer an administration tool called cPanel that offers an interface for hosting tasks such as email and domain management. cPanel also offers a File Manager feature that you can use to upload files and perform other file management chores.
  • Use the web host’s proprietary upload tool. For some reason, a few web hosts only offer their own proprietary interface for uploading and messing around with files and directories. See your host’s Help or Support page for instructions.

Making changes to your web files

What happens if you send a web development file to your web host and then realize you’ve made a typing gaffe or you spy a coding mistake? Or what if you have more information to add to one of your web pages? How do you make changes to the files you’ve already sent?

Well, here’s the short answer: You don’t. That’s right, after you’ve sent your files, you never have to bother with them again. That doesn’t mean you can never update your site, however. Instead, you make your changes to the files that reside on your computer and then send these revised files to your web host. These files replace the old files, and your site is updated just like that.

warning Be sure you send the updated file to the correct directory on the server. Otherwise, you may overwrite a file that happens to have the same name in some other directory.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.191.174.168