Chapter 9: Query Strings

Google

Controlling a process

Query strings can also be used to influence the behavior of your scripts. This is very powerful as you'll see in a moment. They can control how your web page looks on the screen as well. That's more powerful than you can imagine! Why? Because it's part of the basis of building dynamic web pages.

One of the best examples of this is an affiliate link. It will usually contain an affiliate ID of some kind in the query string. For example:

http://www.mysite.com/sales/orders.php?aid=20054

This link always loads the same page regardless of the actual value of the affiliate ID. Many affiliates may think it's their own page but that's unlikely. Let's assume that the affiliate link is taking a customer to the order page. On that page is the order form. The code that displays the order form would first read the affiliate ID. Then it would display the form with $aid(in this example, 20054) as the value of a hidden input like this:

<INPUT TYPE="hidden" NAME=aid VALUE=20054>

Be sure you understand this. The line of HTML you just saw was sent to the browser. The value (20054) was substituted into the actual HTML by your PHP code. The value was passed into the script through a query string. The line of code in your script looked like this:

<INPUT TYPE="hidden" NAME=aid VALUE="$aid">

So here's the path the data followed: The aid was in the query string portion (?aid=20054) of the affiliate link somebody followed to get to your web page. The PHP code created the variable $aid and assigned the value (20054) to $aid. Then, when it echoed the line of code above to the screen as part of a form, PHP automatically replaced $aid with its value - the actual affiliate ID (20054). Since it was a "hidden" input, it didn't show on the page. But its value was associated with the NAME aid and it could be passed to the same script or to a different script altogether.

Did you notice that I used the same name again? In the hidden form field aid isn't a variable yet so there's no conflict. When it's passed into the next script, it will become a local variable called $aid. You can use this trick to make it easy to follow values being passed through a chain of scripts! Just open all of them in a text editor and do a search for the name (in this case, "aid"). Don't include the $ in your search; you want to find it as both a name and a variable.

One exception is when you pass data to a remotely-hosted script such as one provided by a merchant account's payment gateway server. Their script may expect specific field names that you're not allowed to change. Remember that when you send data to someone else's code you have to abide by their rules if you expect it to work correctly. Their script may be in another language (Perl, ASP, etc.). This is no problem. Just make sure your code does its job and let the other code do its job. Then everything will work out just fine.

When the form is processed, the value of $aid is passed along with all the other form inputs to a script that will take some action (collect the money and deliver the goods, presumably). This second script can take the affiliate ID, the date, the product information, etc. and log the sale in a file or a database. This way, there will be a record of the order tied to that affiliate ID.

Code that reads the sales records later can show the affiliate and the program owner the sales made by this affiliate and total up the commissions due. At the time the order is placed, the ID could be used to look up that affiliate's email address and send out a message confirming that a sale had been made. Great care must be taken with the timing! You don't want to notify an affiliate until the sale is complete - in other words, until the payment has been received.

While I'm on the subject of reading sales records, let me point out something. Sales records can be stored in a simple text file in which one line in the file is the record of one sale. That line might contain the time/date, product name, affiliate ID, price and whatever other information you (or the author of the code) decided was worth storing.

Finding the data about the sales made by one affiliate is as simple as reading through the file line by line and ignoring all the lines that don't have the affiliate's ID in them (in the proper place, of course). This is OK for a fairly small number of affiliates and a fairly small volume of sales. But you don't want to stay small. Do you?

For a large amount of data, this method will become very slow. It's really pretty slow anyway. You just don't notice it at first because computers are fast. But when there are a lot of lines in the file (say, 10,000 or more), it takes a noticeable amount of time to find the ones you want. That's where a database comes in handy. It has indexes.

These indexes make it much faster to locate just the data you want as opposed to digging through thousands of lines of text and doing comparisons on every line. On most decent web hosts you'll be able to create MySQL databases (sometimes you're limited to one database - but there are ways to work around that limitation).

I want you to be able to do things right the first time so you won't have to waste time doing them over. So I'll just skip the bits about using text files for storing formatted data. But for those of you who only want to be able to get and use good pre-written PHP scripts, the lesson is clear: Don't invest money in a script that would have to serve a lot of users and store a lot of data unless it uses a database and preferably MySQL.

Previous Page   Table of Contents   Next Page

Copyright © 2004 Steve Humphrey