Web Design/Getting Your Site On the Web

Web Design → Getting Your Site On the Web

This page is part of the Web Design project.

Introduction

After you have a website on your computer, it can not be seen by anyone. It first needs to be put on the internet, or world wide web. Here we will explain this process.

Web Host

Web server software

Guides

Linux Apache MySQL Perl/PHP/Python server (Common LAMP) - Linux, Apache, MySQL, PHP/Perl - maybe simply make really common, stable web servers, but to many cases, it took real computing knowledge to operate for more stable or advanced usage, for example when you are using a server version of Linux.
Windows with Apache MySQL Perl/PHP/Python (also called "WAMP") - use your Windows as a web server.
Mac OS X with Apache MySQL Perl/PHP/Python (also called "MAMP") - use your Mac as a web server.

Windows,Linux,Solaris and Mac OS X with Apache MySQL Perl/PHP (also called "XAMPP") - XAMPP is also included phpMyAdmin and more(depending upon OS and version).

More

Apart from Linux and MacOS X, there are many other Unix systems you could use such as DragonflyBSD, FreeBSD, OpenBSD, PC-BSD and OpenSolaris.
lighttpd and nginx are lightweight alternative to Apache that emerged relatively recently and are becoming popular.
For Microsoft Windows users, there is IIS also available.

Hosts

First, you will need a host. They store your data and show your website to surfers.

There are many reliable hosts who will host your website for a fixed amount each month/year. This is useful if you're prepared to fork out money for your minuscule little project on such extras as "shopping carts" and scripts which you are never likely to use. Otherwise, get free hosting.

You'll agree, that if you ever decide to make a halfway decent website that you'll actually use, it's a far better idea to invest money into your time. It means stability, and above all (seriously, will you look at the state of some of these sites?), professionalism. I would however advise to start out with a free host, and if your project ever gains momentum, then invest some money into getting good hosting.

Alternatively, you could configure a server out of your own computer. This requires a more-or-less static IP address from your Internet Service Provider (ISP), and strict security policies on your "server." There are services, such as Dynamic DNS that allow you to point a URL that you own to your own computer, no matter what the IP address changes to, but these can be tricky to configure. Running a web server "out of your garage" also has power and up-time implications. The system must be stable enough to provide service at almost any time so that potential visitors will actually be able to access your website.

FTP

FTP stands for file transfer protocol. There are two components to this process: a server, and a client. The server is located on the same machine as the data, usually (for simplicity, we'll assume this scenario). An FTP server accommodates either authenticated or anonymous login. Every web hosting server has an FTP server for remote administration of that web site. The other side is the client, which must send the authentication information (or the username "anonymous" and, typically, an email address as the password). The client pushes or pulls files from the server; all actions initiate on the client, making requests on the server either to accept a file upload to the server or to serve a file for download by the client.

It is important to note that FTP traffic is unencrypted, which means that if someone "snooping" on the line intercepted the string of data coming out of your client box, it would be readable in its original form. The possibility of this snooping is another debate, but there is an encrypted alternative in use on web services that cost a bit more. Secure Shell services (ssh) provide a Secure FTP protocol, by which all the traffic is encrypted, so that an interception of that data would be no compromise to data whatsoever.

Control Panel

Some hosts allow you to control your site from your web browser. This makes the configuration of your site easier, but the actual administration of content should be done with a lower-level protocol, like FTP or Secure FTP (SFTP).

Testing

After the site is online, navigate to your site and see how well it looks and performs. You should find out how it works on all common browsers, with various connections, and operating systems.

Here are some suggestions as to the breakdown of those testing areas:

Note: in latest trend you should also test these on mobile platform such as ipad, iphone, andorid smart phones, blackberry phones.

Browsers

Connections

Take into account low-bandwidth users, such as 56k connections
Take into account proxy-based connections
Take into account firewalled users within corporate or educational intranets whose internet access is heavily filtered. The biggest consideration in this category is other servers that are in the chain of connection between your web documents and the end user. Sometimes the packets can become "tainted" in transmission.

Operating Systems

Microsoft Windows
GNU/Linux
Macintosh OS X
Various BSD

If you have written your site in W3C compliant (X)HTML, you should also get it validated.

Tips

Redirect after login

Sites commonly use an URL parameter to return the user to the previously viewed page when logging in or out. On MediaWiki, it is returnto=. Other common names used for this parameter are dest= (“destination”), next=.

On some sites however, this URL parameter only works when logging in, and redirects to the home page instead when the user is already logged in. For the following reasons, the return redirect should be always working, regardless of whether the user is already logged in or logged out:

The user might reload a tab with return URL visited prior to login.
On some mobile phone browsers such as Chrome, switching between mobile/desktop viewing modes causes redirects to the current page be re-followed, which would cause an already logged user to be kicked back to the home page rather than the desired page.
Return URLs that always work enable invitation URLs that encourage users to log in, but redirect already logged users to the correct target rather than the home page.