chapter 9: developing practical php/mysql projects1 208 chapter 9: developing practical php/mysql...

208

Chapter 9: Developing Practical PHP/MYSQL Projects1

Objectives: After reading this chapter you should be entertained and learned to: 1. Using PHP and MySQL for Large Projects. 2. Developing User Authentication and Personalization. 3. Developing A Shopping Cart. 4. Developing A Content Management System. 5. Developing A Web-Based Email Service. 6. Developing A Mailing List Manager. 7. Developing Web Forums. 8. Creating a Bulletin Board System.

9.1 Using PHP and MySQL for Large Projects:

When you are building real world Web applications, things are rarely as simple as building examples in the previous chapters. There was a time a few years ago when an “interactive” Web site had form mail and that was it. However, these days, Web sites have become Web applications—that is, a regular piece of software delivered over the Web. This change in focus means a change in scale. Web sites grow from a handful of scripts to thousands and thousands of lines of code. Projects of this size require planning and management like any other software development.

You need to apply all Software Engineering concepts when developing large Web projects, specifically you need to review:

• Applying software engineering to Web development • Planning and running a Web application project • Re-using code • Writing maintainable code • Implementing version control • Choosing a development environment • Documenting your project • Prototyping • Separating logic, content, and presentation: PHP, HTML, and CSS • Optimizing code

9.2 Developing User Authentication and Personalization:

In this project, you will get users to register at your Web site. When they’ve done that, you will be able to keep track of what they’re interested in and show them appropriate content. This is called user personalization. More generally, user personalization can be used in almost any Web-based application to show users the content they want in the format in which they want it. Also, you can use that information to build what is called click analysis. Figure 9.1 shows the main modules of the user authentication and personalization.

Figure 9.1 shows the main modules of the user authentication and personalization.

1 . . . This chapter was re-tailored from Luke Welling Book.

209

Logging in and authenticating users was implemented in the case study page 161 in this book. You should add to it the required following modules:

• Managing passwords • Recording user preferences • Personalizing content • Recommending content based on existing information about a user.

9.3 Developing A Shopping Cart:

The term shopping cart (sometimes also called a shopping basket) is used to describe a specific online shopping mechanism. As you browse an online catalog, you can add items to your shopping cart. When you’ve finished browsing, you check out of the online store—that is, purchase the items in your cart. In order to implement the shopping cart, we will implement the following functionality:

• A database of the products we want to sell online. • An online catalog of products, listed by category. • A shopping cart to track the items a user wants to buy. • A checkout script that processes payment and shipping details. • An administration interface.

Figure 9.2 A Shopping Cart.

9.3.1 Tracking a User’s Purchases While Shopping:

There are two basic ways we can track a user’s purchases while shopping. One is to put the selected into a database, and the other is to use a session variable. Using a session variable to track selections from page to page will be easier to write as it will not require us to constantly query the database for this information. It will also avoid the situation where we end up with a lot of junk data in the database from users who are just browsing and change their minds.

We need, therefore, to design a session variable or set of variables to store a user’s selections.

When a user finishes shopping and pays for her purchases, we will put this information in our database as a record of the transaction. We can also use this data to give a summary of the current state of the cart in one corner of the page, so a user knows at any given time how much she is planning to spend.

9.3.2 Payment:

In this project, we will add up the user’s order and take the delivery details. We will not actually process payments. Many payment systems are available, and the implementation for each one is different. We will write a dummy function that can be replaced with an interface to your chosen system.

210

The payment system will transmit your data to a bank, and return a success code of one of many different types of error codes. In exchange for passing on your data, the payment gateway will charge you a setup or annual fee, and a fee based on the number or value of your transactions. Some providers even charge for declined transactions.

Your chosen payment system will need information from the customer (such as a credit card

number), identifying information from you (to specify which merchant account is to be credited), and the total amount of the transaction.

9.3.3 Administration Interface:

You will build an administrator interface that will let us add, delete, and edit books and categories from the database. One common edit that we might make is to alter the price of an item (for example, for a special offer or sale). This means that when we store a customer’s order, we should also store the price she paid for an item. It would make for an accounting nightmare if the only records we had were what items each customer ordered, and what the current price of each is. This also means that if the customer has to return or exchange the item, we will give her the right amount of credit. 9.3.4 Solution Overview:

Let’s put all the pieces together. There are two basic views of the system: the user view and the administrator view. After considering the functionality required, we came up with two system flow designs, one for each. Figure 9.3 shows the user view of the system.

Figure 9.3 the user view of the system.

Figure 9.4 shows the administrator view of the system.

Figure 9.4 the administrator view of the system.

211

9.3.5 Extending the Project:

We have built a fairly simple shopping cart system. There are many additions and enhancements we could make:

• In a real online store, you would need to build some kind of order tracking and fulfillment system—at the moment, there’s no way to see the orders that have been placed.

• Customers want to be able to check the progress of their orders without having to contact you. We feel that it is important that a customer does not have to log in to browse.

• However, providing existing customers a way to authenticate themselves gives them the ability to see past orders, and gives you the ability to tie behaviors together into a profile.

• You could add user login, personalization, and book recommendations; online reviews; affiliate programs; stock level checking; and so on. The possibilities are endless.

9.4 Developing A Content Management System:

A content management system is used for storing, indexing, and searching text and multimedia content. Content management systems are extremely useful on Web sites where the site content is maintained by more than one author, where maintenance is performed by non technical staff, or where the content and graphic design are developed by different designers. We will build a system that helps authorized users to manage an organization’s digital assets. We will cover:

• Presenting Web pages using a series of templates

• Building a search engine that indexes documents according to metadata 9.4.1 The Problem Definition:

Let’s imagine that the busy Web development team for NewsOnLine consists of an excellent graphic designer and some award-winning writers. The site contains regularly updated news, sports, and weather pages. The main page shows the latest headline from each of the three category pages.

At NewsOnLine, most designers ensure that the Web site content looks great. This is what they

do best. Writers, on the other hand, write excellent articles, but can’t draw well or build Web sites. We need to allow everyone to concentrate on what they are best at and bring their output together to provide the super fast news service that the name implies. 9.4.2 Solution Requirements:

We need to produce an application that: • Increases productivity by having the writers concentrate on writing and the designers on

designing. • Allows the editor to review stories and decide which ones should be published. • Presents a consistent look and feel throughout the site using page templates. • Allows writers access only to their designated areas of the site. • Enables the look and feel to be easily changed for a section or throughout the site. • Prevents live content from being changed.

9.4.2.1 Editing Content:

First, we need to think about how we will get content into the system, and how we will store and edit that content. 9.4.2.2 Getting Content into the System:

We need to decide on a way that stories and design components will be submitted. Three possible methods can be used.

212

9.4.2.3 FTP:

The writers and designers could be given FTP access to areas on the Web server, and they could then upload files from their local machine to the server. There would need to be a rigid naming standard for the uploaded files (to identify which pictures belonged to which stories) or a Web-based system to deal with this separately from the FTP upload. Using FTP also creates issues with permissions in this situation. Because of the flexibility required by this example, we will not be using FTP to allow users to upload files. 9.4.2.4 File Upload Method:

The HTTP protocol provides a method for files to be uploaded via the Web browser. PHP is able to deal with this very easily. The file upload method also gives us the opportunity to store text in a database rather than as a file. To do this, we would read in the temporary file and store its contents in the database, rather than copying it to another place in the file system. We will not use file upload for stories in this project. 9.4.2.5 Editing Online:

We can let users create and edit documents without using either FTP or file upload. Instead you can give the contributors a large text area input box onscreen in which their story content can be edited. This method is simple, but often effective. The Web browser does not provide any text editing facilities beyond the cut-and-paste functionality of the operating system. However, when you just need to make a small change—for instance, to correct a spelling mistake—it’s very fast to bring up the content and amend it. Similar to file upload, the form data could either be written to a file or stored in a database. 9.4.3 Design Layout:

Let us take the layout of www.ahram.org.eg as the layout of our NewsOnLine. The layout is shown in figure 9.5.

Figure 9.5 www.ahram.org.eg layout.

213

9.4.4 A Subject Input Form:

You may design a form for each subject like the following form in figure 9.6.

Figure 9.6 A Subject Input Form.

Note: the “Browse” can be got by using the tag: <INPUT TYPE=FILE NAME=”picture” SIZE=40> When clicking the “Browse” button, it would popup a panel to determine what file you need to

browse (as shown in figure 9.7.

Figure 9.7 the result of clicking “Browse” button.


There are several ways this project could be extended to make a more comprehensive content management system:

• You could allow groups of users to work on stories together (collaboration). • You could implement a more flexible page layout so that editors can position text and

images on the page.

214

• An image library could be built so that frequently used pictures are not duplicated, and search keywords are assigned to images as well as story text.

• You could also add spell-checking functionality to the content editor. A check could be implemented using, for example, the “a spell” library.

9.5 Developing A Web-Based Email Service

If you remember the story of the hoopoe and the Messenger Suleiman, you will realize the importance of mail messages. More and more often these days, sites want to offer Web-based email to their users. This section explains how to implement a Web interface to an existing mail server using the PHP IMAP library. You can use it to check your own existing mailbox through a Web page, or perhaps extend it to support many users for mass Web-based email like Hotmail. In this project, we will build an email client, Warm Mail, that will enable users to:

• Connect to their accounts on POP3 or IMAP mail servers. • Read mail. • Send mail. • Reply to mail messages. • Forward mail messages. • Delete mail from their accounts.

9.5.1 The Problem:

In order for a user to be able to read his mail, we will need to find a way to connect to his mail server. This generally won’t be the same machine as the Web server. We will need a way to interact with his mailbox, to see what messages have been received and to deal with each message individually. Two main protocols are supported by mail servers for reading user mailboxes: POP3 and IMAP.

If possible, we should support both of these. POP3 stands for Post Office Protocol version 3, and IMAP stands for Internet Message Access Protocol. The main difference between these two is that POP3 is intended for, and usually used by, people who connect to a network for a short time to download and delete their mail from a server. IMAP is intended for online use, to interact with mail permanently kept on the remote server. IMAP has some more advanced features that we won’t use here.

If you are interested in the differences between these protocols, you can consult the RFCs for them (RFC 1939 for POP version 3 and RFC 2060 for IMAP version 4 rev1). An excellent article comparing the two can be found at http://www.imap.org/papers/imap.vs.pop.brief.html

Neither of these protocols is designed for sending mail—for that we must use the SMTP (Simple Mail Transfer Protocol), which we have used before from PHP via the mail() function. This protocol is described in RFC 821. 9.5.2 Solution Components:

PHP has excellent IMAP and POP3 support, but it is provided via the IMAP function library. In order to use the code presented in this chapter, you will need to have installed the IMAP library. You can tell if you already have this installed by looking at the output of the phpinfo() function. If not, you will need to download the extension. You can get the latest version via FTP from

ftp://ftp.cac.washington.edu/imap/c-client.tar.Z Under UNIX, download the source and compile it for your operating system. When you have

done this, copy rfc822.h, mail.h, and linkage.h to /usr/local/include or another directory in your include

215

path, run PHP’s configure script, adding the --with-imap directive to any other parameters you use, and recompile PHP.

Documentation exists on compiling the Windows version yourself, but it is much more complex than compiling for UNIX. If you are using a Windows platform, there is an easier alternative. You can download a precompiled version of PHP compiled with various extensions, including the IMAP extension, from

http://www.php4win.de One interesting thing to note is that although these are called IMAP functions they also work

equally well with POP3 and NNTP (Network News Transfer Protocol). We will use them for IMAP and POP3, but the Warm Mail application could be easily extended to use NNTP.

A very large number of functions are in this library, but in order to implement the functionality in this application, we will use only a few. We’ll explain these functions as we use them, but be aware that there are many more. See the documentation if your needs are different from ours, or if you want to add extra features to the application.

You can build a fairly useful mail application with only a fraction of the built-in functions. This

means that you need only plow through a fraction of the documentation. The IMAP functions we use in this chapter are: imap_open(), imap_close(), imap_headers(), imap_header(), imap_fetchheader(), imap_body(), imap_delete(), imap_expunge().

For a user to read his mail, we will need to get his server and account details. Rather than getting these details from the user every time, we’ll set up a username and password database for a user so that we can store his details.

Often people have more than one email account (one for home and another for work, for example), and we should allow them to connect to any of their accounts. We should therefore allow them to have multiple sets of account information in the database. We should enable users to read, reply to, forward, and delete existing emails, as well as send new ones. We can do all the reading parts using IMAP or POP3, and all the sending parts using SMTP with mail(). 9.5.3 Solution Overview:

The general flow through this Web-based system won’t be much different from other email clients. A diagram showing the system flow and modules is shown in figure 9.8

Figure 9.8 e-mail solution components.

9.5.4 Screens Layout:

We can start with the “www.yahoo.com” mail system (shown in figure 9.9, till figure 9.20).

216

Registering for new account.

Figure 9.9 yahoo screens 1,2.

Completing the user profile.


Logging into the system.

Figure 9.11 yahoo screens 5

Browsing the mail contents.

Figure 9.12 yahoo screens 6, 7

217

Checking a mail message or composing a new message.


Browse to get attached files.


Preparing and sending a new message.


Setting the general preferences.

Figure 9.16 yahoo screens 14, 15.

218

Setting a signature.

Figure 9.17 yahoo screens 16.

Setting vacation response.


Setting other emails


Searching mails.


219

9.6 Developing A Mailing List Manager:

We will implement a front end for a mailing list manager (or MLM). Some MLMs allow each subscriber to send messages to other subscribers. Our program will be a newsletter system, in which only the list administrator can send messages. We will call our system Pyramid-MLM. This system will be similar to others already in the marketplace. To get some idea of what we are aiming for, take a look at http://www.topica.com.

Our application will let an administrator create multiple mailing lists and send newsletters to each of those lists separately. This application will use file upload to enable an administrator to upload text and HTML versions of newsletters that they have created offline. This means administrators can use whatever software they prefer to create newsletters. Users will be able to subscribe to any of the lists at our site and select whether to receive newsletters in text or HTML.

9.6.1 The Problem Definition:

We want to build an online newsletter composition and sending system. This system should allow various newsletters to be created and sent to users, and allow users to subscribe to one or many of the newsletters. Specifically, the requirements for this system are:

• Administrators should be able to set up and modify mailing lists. • Administrators should be able to send text and HTML newsletters to all the subscribers of a

single mailing list. • Users should be able to register to use the site, and enter and modify their details. • Users should be able to subscribe to any of the lists on a site. • Users should be able to unsubscribe from lists they are subscribed to. • Users should be able to store their preference for either HTML formatted or plain text

newsletters. • For security reasons, users should not be able to send mail to the lists or to see each other’s email

addresses. • Users and administrators should be able to view information about mailing lists. • Users and administrators should be able to view past newsletters that have been sent to a list (the

archive).

9.6.2 Solution Components:

There are a number of components we will need to fulfill the requirements. The main ones are setting up a database of lists, subscribers, and archived newsletters; uploading newsletters that have been created offline; and sending mail with attachments.

9.6.2.1 Setting Up a Database of Lists and Subscribers:

We will track the username and password of each system user, as well as a list of the lists they have subscribed to. We will also store each user’s preference for receiving text or HTML email, so we can send a user the appropriate version of the newsletter.

An administrator will be a specialized user with the ability to create new mailing lists and send newsletters to those lists. A nice piece of functionality to have for a system like this is an archive of previous newsletters. Subscribers might not keep previous postings, but might want to look something up. An archive can also act as a marketing tool for the newsletter as potential subscribers can see what the newsletters are like. Setting up this database in MySQL and an interface to it in PHP will have nothing new or difficult in it.

9.6.2.2 File Upload:

We need an interface to allow the administrator to send newsletters, as mentioned previously. What we haven’t talked about is how administrators will create that newsletter. We could provide them with a form where they could type or paste the newsletter content. However, it will increase the user-friendliness of our system to let administrators create a newsletter in their favorite editor and then

220

upload the file to the Web server. This will also make it easy for an administrator to add images to an HTML newsletter.

We will need to use a slightly more complicated form than we have used in the past. We will require the administrator to upload both text and HTML versions of the newsletter, along with any inline images that go into the HTML. When the newsletter has been uploaded, we need to create an interface so that the administrator can preview the newsletter before sending it. This way, he can confirm that all the files were uploaded correctly.

9.6.2.3 Sending Mail with Attachments:

For this project, we would like to be able to send users either a plain text newsletter or a "fancy" HTML version, according to their preference. To send an HTML file with embedded images, we will need to find a way to send attachments.

PHP’s simple mail() function doesn’t easily support sending attachments. Instead, we will use the excellent HTML MIME Mail class created by Richard Heyes. This can deal with HTML attachments, and will automatically attach any images that are contained in the HTML file. You can get the most up-to-date version of this class from

http://www.heyes-computing.net/scripts/ You are free to use this script in your own work. It is released as Postcard-Ware. If you use it,

send the author a post card. The address is on his Web site.

9.6.3 Solution Overview:

We have again begun by drawing a set of system flow diagrams to show the paths users might take through the system. In this case, we have drawn three diagrams to represent the three different sets of interactions users can have with the system. Users have different allowable actions when they are not logged in, when they are logged in as regular users, and when they are logged in as administrators.

Figure 9.21 Main components.

Figure 9.22 More detailed.

221

Figure 9.23 full system details.


As usual with these projects, there are many ways you could extend the functionality. You might like to:

• Confirm membership with subscribers so that people can’t be subscribed without their permission. This is typically done by sending email to their accounts and deleting those who do not reply. This approach will also clean out any incorrect email addresses from the database.

• Give the administrator powers to approve or reject users who want to subscribe to their lists. • Add open list functionality that allows any member to send email to the list. • Let only registered members see the archive for a particular mailing list. • Allow users to search for lists that match specific criteria. For example, users might be

interested in golf newsletters. Once the number of newsletters grows past a particular size, a search would be useful to find specific ones.

9.7 Developing Web Forums:

Web forums are sometimes also called discussion boards or threaded discussion groups. The idea of a forum is that people can post articles or questions to them, and others can read and reply to their questions. Each topic of discussion in a forum is called a thread. We will implement a Web forum called blah-blah with the following functionality. Users will be able to:

• Start new threads of discussion by posting articles • Post articles in reply to existing articles • View articles that have been posted • View the threads of conversation in the forum • View the relationship between articles, that is, see which articles are replies to other articles.

9.7.1 The Problem Definition:

Setting up a forum is actually quite an interesting problem. We will need some way of storing the articles in a database with author, title, date, and content information. However, the way most threaded discussion software works is that, along with showing you the available articles, it will show you the relationship between articles. That is, you are able to see which articles are replies to other articles (and which article they’re following up) and which articles are new topics of discussion.

You can see examples of discussion boards that implement this in many places, including Slashdot: http://slashdot.org

Deciding how to display these relationships will require some careful thought. For this system, a user should be able to view an individual message, a thread of conversation with the relationships shown, or all the threads on the system. Users must also be able to post new topics or replies. This is the easy part.

222

9.7.2 Solution Components:

The most difficult part of this application is finding a database structure that will store the information we want, and a way of navigating that structure efficiently.

Figure 9.24 forum navigation structure.

In this diagram, you can see that we have an initial posting starting off a topic, with three

replies. Some of the replies have replies. These replies could have replies, and so on. Looking at the diagram gives us a clue as to how we can store and retrieve the article data and the links between articles.

This diagram shows a tree structure. If you’ve done much programming, you’ll know that this is one of the staple data structures used. In the diagram there are nodes—or articles—and links—or relationships between articles—just as in any tree structure.

The tricks to getting this all to work are: 1. Finding a way to map this tree structure into storage—in our case, into a MySQL database. 2. Finding a way to reconstruct the data as required.

We will begin by implementing a MySQL database that will enable us to store articles between use. 9.7.3 Solution Overview:

To really understand what we have done with this project, it’s probably a good idea to work through the code, which we’ll do in a moment. There is less bulk in this application than in some of the others, but the code is a bit more complex. There are only three real pages in the application.

We will have a main index page that shows all the articles in the forum as links to the articles. From here, you will be able to add a new article, view a listed article, or change the way the articles are viewed by expanding and collapsing branches of the tree. From the article view, you will be able to post a reply to that article or view the existing replies to that article. The new article page enables you to enter a new post, either a reply to an existing message, or a new unrelated message. The system flow diagram is shown in figure 9.25.

Figure 9.25 System flow diagram.


There are many extensions you could add to this project:

223

• You could add navigation to the view options, so that from a post you could navigate to the next message, the previous message, the next-in-thread message, or the previous-in thread message.

• You could add an administration interface for setting up new forums and deleting old posts. • You could add user authentication so only registered users could post. • You could add some kind of moderation or censorship mechanism.

9.7.5 Using an Existing System:

There are a couple of noteworthy existing systems. Phorum is an Open Source Web forums project. It has different navigation and semantics from ours, but its structure is relatively easily customized to fit into your own site. A notable feature of phorum is that it can be configured by the actual user to display in either a threaded or flat view. You can find out more about it at

http://www.phorum.org Another interesting project is phpslash. This is a port of the software used to run the Slashdot

discussion boards. Although the original software is written in Perl, this PHP version is available. You can get it from http://www.phpslash.org

chapter 9: developing practical php/mysql projects1 208 chapter 9: developing practical php/mysql...

Documents