So, you’ve decided to build a Web site. You’ve got a neat idea that you think others would enjoy. Or you’ve got a product to sell, and you want to get into the e-commerce sphere and make a few bucks. It’s an excellent decision, regardless of the reason. Building a Web site is fun and entertaining, and it’s a great learning experience.
Of course, to begin with, you need to have a little knowledge of HTML, but there are other things that you need to consider, as well. Are you going to host the site yourself, or will someone else host it for you? In most cases, letting someone else host your site will cost you money, and procuring a good host may cost you a lot of money. Does your host have the necessary tools? Is your host able to use Perl and PHP for your Web pages? Does your host use an efficient Web server on an efficient operating system? If you decide to host your site yourself, do you have enough flexibility to maintain the site? But beyond these basic questions lies a more important question. Will your Web site be static or dynamic? For those of you who are unfamiliar with these terms, let me explain.
Static Web sites
A static Web site is one that you update locally and upload to the Web server manually. For instance, you would create your Web page, test it locally, and upload it to the Web server in order to test it again. The content of the page changes only when you change it personally, either by changing a locally saved page or by downloading the page from the Web server and then editing it. This process can involve a lot of work, especially if you want fresh content to appear regularly. For example, if you wanted to add news headlines to your site, you would have to add those headlines manually, and you would have to go through the uploading process every time you decided to change it. For a large site with a lot of information that changes on a daily basis, you’d be looking at a lot of extra work. Take a look at any of these popular portal sites: Slashdot, freshmeat.net, or Freezer Burn. These sites contain a lot of information that gets updated many times each day. If you think that these sites are static Web sites, you must think that they have an army of HTML writers who update pages around the clock.
Dynamic Web sites
I can assure you that it isn’t the case. Those sites—and many like them—use the dynamic Web site model. A dynamic Web site is always changing. Typically, it relies on some sort of database that stores the information that will appear on its pages. Interaction between the Web pages and the database will occur on a real-time basis. Thus, the number of Web pages to produce is drastically reduced. Instead of designing individual pages, you’ll design templates that use a special programming code to format and display the information in the database for someone who’s visiting your site.
The advantages to this model are obvious. Instead of creating hundreds of Web pages, you may only create a few pages (or templates) that will be reused to display different information. No manual editing, updating, or uploading of pages will occur. Typically, a back-end form will allow Web administrators to make any necessary changes. If you combine the database-driven dynamic Web site with Cascading Style Sheets, the time and effort that it takes to overhaul your site completely is minimal in comparison to a similar static site. In short, dynamic Web sites are much easier to maintain than static Web sites, no matter how you look at it. The real work comes at the beginning, when you set up the dynamic site. After that initial setup, however, the later work becomes much simpler.
In this series, I’ll explain how to create a dynamic Web site with the following tools: Apache, MySQL, PHP, and Perl. All of these tools are invaluable to maintaining a good dynamic Web site. I’ll also tell you how to perform the necessary tasks on your Linux server. As long as you can run your own server on the Internet and you take some initial precautions to keep visitors to your site only where you want them, you’ll discover that the benefits of running your own Web server in-house more than outweigh the costs.
The Apache Software Foundation, a nonprofit organization that provides organizational, legal, and financial support for Apache projects, wrote the Apache Web server. In Apache’s own words, “The Apache Project is a collaborative software development effort aimed at creating a robust, commercial-grade, featureful, and freely-available source code implementation of an HTTP (Web) server.” They call the Apache Web server a powerful, flexible, HTTP/1.1-compliant Web server. Considering that roughly 60 percent of all Web servers that currently run on the Internet are Apache Web servers (according to a Netcraft survey that was conducted in May of 2000), it’s safe to assume that Apache is a good—and popular—choice.
Apache also provides a great deal of flexibility and versatility, which any Web administrator would appreciate. It’s available for almost every flavor of Linux, UNIX, Windows, OS/2, and BeOS! A lot of Apache’s strength comes from the fact that it’s a modular Web server. Through the use of modules, Apache can support many external programming and scripting languages, and it can add enhanced functionality to the core server without sacrificing extra memory or CPU requirements. You can add or reduce any function that’s included in a module without recompiling the source code.
An alternative to Apache that’s growing very popular is a Web server called Roxen. It, too, runs on virtually every platform—from Linux and the different flavors of UNIX to Windows and Macs. The only platform that isn’t supported is BeOS. Roxen provides database access support internally, without requiring Perl or PHP to accomplish it. It also supports popular scripting languages like Perl and PHP. Although not as popular as Apache, Roxen is creating its own following as it matures. Like Apache, Roxen is free. It may be worth examining. For the purposes of this Daily Drill Down, however, we’ll use Apache as our Web server.
Database back ends
For a dynamic Web site to be truly effective, you must have a database back end. Your dynamic content will be stored in the database, and your dynamic pages will simply retrieve that information from the database. You could use static text pages for your dynamic content, but doing so would defeat the purpose of being able to administrate your Web site remotely, which is the primary reason for creating a dynamic Web site.
Let’s take the news headline example. Ideally, you would retrieve the information for each news headline from the database and display it on your dynamic pages. But that’s only half of the process. Instead of using a clumsy command for inserting directly into your database, you could secure a back-end portion of your Web site with an administrator’s form, and you could add news items directly into the database. With this approach, you’d never need to upload a file or fiddle with clumsy SQL syntax in order to insert items into your database. The form that you create would do the work for you. Both retrieval and insertion would be performed through your Web site, making your life a lot easier. The benefit to using this method would be that you could allow other users to add content to your Web site without granting them shell access or root privileges on your system.
One of the most popular back-end databases is MySQL, a cross-platform Relational Database Management System (RDMS). A relational database is like a spreadsheet. It contains rows and columns of data. Each “spreadsheet” is referred to as a table. Tables can be related to each other through the use of “keys” or common data elements. Thus, you can use multiple tables to represent information that’s similar, yet you can separate these tables in order to maintain them more easily. Of course, as the name implies, MySQL uses a programming language called SQL (Structured Query Language). This language will help you insert, delete, or otherwise modify the content of your database.
Since MySQL is light and very resource-efficient, it makes an ideal back end for any Web site, large or small. The querying and retrieval of information from within your dynamic pages will become very fast, and most users will never know that you’re using a database back end to display the information. Obviously, it won’t be the same if you run a largely dynamic Web site on a 386 computer. On a Pentium system with a decent amount of RAM, however, using a MySQL server will give you more than enough speed.
Another good—though not so popular—RDMS is PostgreSQL. PostgreSQL, which is another server-driven database, uses the same SQL language that MySQL does, but it comes with some enhancements. Some people prefer PostgreSQL. Both PostgreSQL and MySQL have unique features, and both are good database servers. Personally, I think that PostgreSQL is a little difficult to set up, and I don’t miss PostgreSQL’s enhancements. Still, I run both databases because some of my users know PostgreSQL better than MySQL. The nice thing about these database servers is that each one listens on a different TCP port; therefore, you can run both servers simultaneously without conflict. For the purposes of this Daily Drill Down, however, we’ll use the MySQL server.
Finally, you must decide which programming language to use on your dynamic Web site. The choices are pretty simple, though. The most popular languages for dynamic Web sites are PHP (Personal Home Pages) and Perl (Practical Extraction and Report Language). You could use either language. PHP was designed for use with Web pages; Perl, though not specifically designed for Web pages, has many modules that provide excellent Web functionality as CGI (Common Gateway Interface) scripts.
PHP is a language that you embed directly into your Web pages. Using the start (<) and end (>) tokens inside a Web page, you can insert PHP code to do whatever you want, provided that your Web server actually supports it. With Apache, PHP support comes as a module, and it’s very easy to include. PHP can be broken up within a Web page. So, you can use looping statements, and you can break in and out of your PHP code in order to write the HTML that formats the information you retrieve from the database. Since PHP supports both MySQL and PostgreSQL (along with many other database servers), it makes for a good choice.
Perl, on the other hand, is an interpreted scripting language that must be used as a CGI script. Thus, you write your Perl program and call it from within your Web page in order to process information (usually as forms). With certain Perl modules installed, however, you theoretically could write an entire Web page within a series of Perl scripts (as many forum-type applications do). To illustrate the power of Perl and PHP, there are many forum applications that are written in these languages. (Forum applications offer users the ability to interact with each other and to discuss topics on Web sites. They’re very similar to the old Bulletin Board Systems that many of us love and remember.) Both languages give the authors of these forum packages the ability to interact with various databases and to store discussion threads, messages, and forum areas. The differences involve the authors’ design concepts and their familiarity with their chosen programming language.
In this series, we’ll take a look at using both Perl and PHP for dynamic Web sites. That way, I can give you an idea of the benefits and drawbacks of each language, and I can give you an idea of when one language would work better than the other.
You’ve just learned a little of the “theory” behind dynamic Web sites. Perhaps I’ve cleared the air about what they are and what they can do, too. Now, you should know more about the mainstream and alternative software that you can use to create a highly effective dynamic Web site. In the following parts of this series, I’ll tell you how to install and set up Apache and MySQL, and I’ll show you how to begin creating your dynamic site. I’ll also explain how you can use PHP and Perl to maintain and improve your site.
Vincent Danen, a native Canadian in Edmonton, Alberta, has been computing since the age of 10, and he’s been using Linux for nearly two years. Prior to that, he used OS/2 exclusively for approximately four years. Vincent is a firm believer in the philosophy behind the Linux “revolution,” and he attempts to contribute to the Linux cause in as many ways as possible—from his FreezerBurn Web site to building and submitting custom RPMs for the Linux Mandrake project. Vincent also has obtained his Linux Administrator certification from Brainbench . He hopes to tackle the RHCE once it can be taken in Canada.
The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.