541-389-7208

Technical Matters

Technical Steps in Creating a Website

These technical steps have to happen to make a new website (steps 4 and 5 are necessary only for database-driven websites, but that is the only kind that I build):
  1. The rights to your domain name, such as mysite.com, must be purchased from a domain name registrar. This will be for a limited period of time, after which the rights will have to be renewed periodically.
  2. Space on a server computer, which is said to host your website, must be rented. This will be for a limited period of time, after which your hosting will have to be renewed periodically.
  3. The files that deliver your website must be created and uploaded to your hosting server.
  4. A supporting database and its tables must be created on your hosting server or a connected server.
  5. Your content must be input into the database, and files associated with that content. such as image files, must be uploaded to your hosting server.
  6. Your content must be revealed to the Internet ("going live").
 
These steps are covered in more detail, along with other aspects of building your website, in other pages in this section of the website. Specifically, steps 1 and 2 are covered in the Preliminaries page, steps 3, 4, and 5 are covered in the Building page, and step 6 is covered in the Getting Found page.

Other Technical Matters (If You're Interested)


When a visitor to your website types in the address of your website or clicks on a link to your website, a conversation of sorts is initiated between two software programs, which run on different computers. The terms server and client technically refer to the two software programs involved, but both, especially server, are also commonly applied to the computer on which they reside and run. Client software initiates requests to server software and receives responses from server software. Server software can only respond to requests.

The client software is a browser, such as Internet Explorer, Mozilla Firefox, Chrome, or Safari. When a visitor to your website types in the address of a page in your website or clicks on a link to your website in their browser, the browser sends a request to the server software on the server computer for it to send it a page that is in your website, which it then does. The page in the request can be explicit, via including its file name, such as contact.html in the Uniform Resource Locator (URL) http://www.yoursite.com/contact.html. When a file name is not included in the URL, the page requested is implicit, namely the home page of your website.

HTML (HyperText Markup Language) is the language of web pages. The server software responds to a browser's request for a page by sending HTML content to the browser. The browser then renders the HTML for the page on the screen. As it processes the HTML, it sends requests back to the server software for additional files, if any, that the HTML says it needs to render the page, such as style sheets, images, and JavaScript files, which the server then sends to the browser.

Server-side programming is, as you would expect, programming that runs on the server. There are several different technologies for server-side programming that can accomplish the kinds of things that I do. I use one of the most popular, namely PHP in conjunction with MySQL databases. I use server-side programming primarily to accomplish two tasks, namely generating content and responding to forms.

Generating Content

When the server software sees a request from a browser for a PHP file, such as contact.php, it tells the PHP processing engine to open and run the file, which contains instructions for the PHP processing engine. When the PHP file is for a web page, the engine will usually be instructed to obtain information from the database and use it to write HTML. Such instructions will typically be interspersed with sections of the file that are already in HTML, which will be passed through the engine unchanged. The resulting HTML will then be sent back to the browser.This is in contrast to an HTML file for a page, such as contact.html, for which the server software sends the contents of the HTML file to the browser without any processing.

This explains how my websites are database-driven, i.e., get most of their content from a database rather than static files. It doesn't explain how the data gets into the database in the first place, however.

Responding to Forms

Website pages often contain forms for user inputs. You may not always recognize them as such, as they may only contain one item, such as a place to input a password. When a form is submitted, the data is sent to the server, along with the name of the file that is to do something with the data. For my websites, that file is again a PHP file that contains instructions for what to do with the data. Again those instructions are read and executed by the PHP processing engine.

The forms that I use are mainly of these two kinds:
  • Forms that website visitors fill out and submit in order to send you an email message. In that case PHP uses the data to compose the email message and then email it to you.
  • Forms that you fill out and submit to input or update content in your website. In that case the PHP uses the data to update the database. Other things may also be involved, such as uploading and manipulating image files.
The latter kind of form is how the data gets into the database. See the CMS section of the website for how you get to those forms and use them and demos of how they work.

Client-side programming is, as you would expect, programming that is executed by client software, namely browsers. Such programming is usually written in JavaScript. When something in a page changes without the delay and movement typically associated with having the server send the page to the client again, JavaScript programming is very likely responsible. The revealing and hiding of the section of the text that you are reading now in response to your clicking on its heading is an example of JavaScript in action, as is the rollover effect when you move the cursor over the navigation links at the top of the page.

Differences between browsers in how they render HTML and how they execute JavaScript are a major headache for website developers. This includes differences between different releases of the same browser. I now use a relatively new tool called jQuery, which acts as a kind of superstructure on top of JavaScript, much more often than plain JavaScript. It takes care of most browser differences behind the scenes and makes it much easier to accomplish many things, including simple animations. I implemented the examples of JavaScript in action mentioned in the preceding paragraph via jQuery.

A technology called AJAX passes information back and forth between JavaScript running on a browser (client-side programming) and programming running on the server (server-side programming). An example is updating only a small portion of a page rather than the whole page in response to user input. In this example, JavaScript sends a request to the server for updated content based on what the user has input, programming running on the server generates the requested content and sends it back to the browser, and JavaScript running on the browser updates the page using the content that it just received. I make some use of AJAX, and I anticipate doing quite a bit more with it in the future.

Although providing a Content Management System (CMS) to my clients is a great advantage of building database-driven websites, it is not the only one. I originally started building database-driven websites for how easy they make it to be consistent, with the ability to easily add controlled differences within that framework.

Consider placing products of a certain type on a page. The file that creates the page will query the database, asking for all products of that type. It will then run a programming loop that creates the HTML that shows a product, once for each of the products to be shown. Since the same programming loop is used for each product, consistency is assured. Furthermore, the way in which the products are placed on the page is easily updated by changing the programming in just one place.

Now consider traditional HTML programming in situations like this, where the HTML for placing each product is separately input into a static file. Ensuring consistency is quite tedious initially, even more so when the way in which the products are placed on the page is to be changed, and even more problematic when individual products are added or updated at different times by different people.

Conditional branching can be added to a loop that produces HTML, so that the HTML produced is not always exactly the same. A simple example is placing products horizontally in a row, but inserting the HTML to move down and start a new row after every third product.

Looping combined with conditional branching can be much more complex. For example, the navigation buttons near the top of each page in this website are always created by the same programming, yet they are different on every page. As a result, you can always tell which page you are currently on, and how it fits into the bigger picture.