|
|
Introduction to PHPA Hands-on How-toSMfrom Brass Cannon ConsultingA little vague handwaving can often save hours of tedious explanation. |
You have to start somewhere.
I'm going to assume that you can write a "hello, world" page in plain HTML, something we cover elsewhere. Simple, right? But let's think for a moment about what HTML is really about.
HTML is, at its root, a way to include markup in a stream of text as it is being displayed. "Markup" is what allows you to specify whether the visible text is large or small, italic or bold, and to enter exotic characters that may not appear on your keyboard. It even allows you to pull in images, simply by giving their names inside markup tags.
Note that the markup itself is supposed to be invisible. You know it is there only because you see its effect on visible text. If you tell your browser that you want to "view source," then you can see the markup language as your browser sees it.
That doesn't mean that you are seeing everything in the source for a page, however. There are two ways to write "source code" for a web page that will remain hidden even if you order your browser to show the raw markup.
One of those methods is CGI scripting. A bit of code is run on the server, and only the output created by that code makes it to your browser. In your browser, on your desktop, there is no way to know where this HTML came from, or that it was generated by a CGI script rather than being part of a prepared page.
CGI has two big drawbacks, though. Only privileged users can be trusted to install code that runs as part of a web server, and any bugs in that code risk giving away control of the server to rude strangers. For that reason CGI code is usually installed in a special "cgi-bin" directory away from the static (unchanging) web content -- and that makes the problem even worse, as doing so makes it very obvious to any would-be hacker that here are knobs to play with and buttons to push.
Another way to create HTML code dynamically -- that is, code that changes, code that is not prepared completely in advance -- is with PHP, a language that is uniquely suited to being included inside web pages. PHP code does not have to be kept in a cgi-bin directory. You need a web server that supports PHP; if it does, it will interpret the PHP code inside your pages as it serves them, changing the stream of text on its way to the visitor's browser. You have the power to edit your pages with each visitor who comes to your site.
How do you know if your server supports PHP? If it's your server, of course, you should know whether you installed PHP or not. But is it working? The way most people check that is to install (and then visit) a one-line page with this content:
<?php phpinfo(); ?>
If your PHP installation is working, you'll get a colorful page chock full of information about your webserver and its configuration. If not, you'll get the line above, uninterpreted.
To start out, look at this HTML "one liner":
<html><head></head><body><h1>Foo</h1></body></html>
That is a complete html page on one line, although all it does is display the Unix nonsense word "Foo" in large type.
This PHP code is exactly equivalent to our one-line page, if it is run on a server that supports PHP:
<html><head></head><body>
<?php
echo ("<h1>Foo</h1>");
?>
</body></html>
To a browser, there is no way to tell these two examples apart. The output that the webserver sends to the browser is exactly the same in both cases.
But as with any programming language, we now have variables, a bit of storage space that we can refer to by name. We have the ability to change the content of the variable -- if you don't want it to say "Foo" you can change it to "Bar":
<html><head></head><body>
<?php
// Has $foo been defined? If not, make it equal "Foo"
if (!$foo) {$foo = "Foo";}
echo ("<h1>$foo</h1>");
?>
</body></html>
Save this to your web-capable machine as "foo.php" and you will be able to run it as "http://localhost/foo.php" -- if you do, it will say "Foo" to you because that is its default value. But you can tell it that you want the variable $foo to contain the value "Bar" instead:
http://localhost/foo.php?foo=Bar
...and it will display a big "Bar" instead of a big "Foo."
If you're not used to writing computer programs, there are a lot of finicky details that we haven't covered yet. They come down to speaking the PHP language using complete sentences, mostly. Computers can't fill in the missing bits without help, or follow vague hand-waving -- you have to close your quoted strings and end each command properly. You'll get a lot of "parse error" messages when you start writing PHP scripts; usually it means something was left unfinished. Look for a missing quote, a parenthesis that is missing its mate, or a missing semicolon at the end of a command.
PHP has many predefined functions -- like "phpinfo();" -- which can do all sorts of things. Mostly they change and combine variables (like $foo) to produce new values. PHP also understands HTML forms, and it is very easy to use an HTML form to assign a value to a PHP variable. PHP also has good support for databases, which makes it the simplest way I know to get data from an HTML page into a MySQL database and back again.
PHP used to be quite generous about the way it handled variables; it was friendly to beginners. You could set up a global variable in one PHP script and keep using it even in a different script, passing it back and forth. Unfortunately, this convenience is also a gaping security hole, since it offers a way for people to push values into the guts of your code, such as changing the price of an item in a shopping cart to get a color TV for twenty cents. As a result, any current PHP installation should not allow you unfettered use of global variables. If you have an older PHP program, I hope it has been rewritten to work after having the "register_globals" switch turned off. If not, you need to do that or pay someone to do it for you.
The edits needed to make your code work without "register_globals" aren't so bad. Let's say you have an HTML form that sends a variable called "$price" to your PHP page. (Forms are a standard part of HTML, so this technique isn't limited to use with PHP.)
<h3>Buy one widget at $15.95</h3> <form action="buy.php" method="POST"> <input type=hidden name=price value="15.95"> <input type="submit">
When someone clicks on the "submit" button in that form, the price is sent to "buy.php" on the same server. In an older version of "buy.php" you might see this:
$myprice = $price;
...and to fix it, you now need something like this:
$myprice = $_POST[price];
The first one used the global variable $price (which should come with a warning label that says "Don't touch that! You don't know where it's been!"). The second version specifies that you want the "price" that is in the "$_POST" array, which contains variables that came from a form and were "passed" to you using the POST method.
For something you do not want to be manipulated, such as an item's price, you would use a form and the POST method, as shown above. For something less sensitive, and especially for things you are willing to have included in the bookmark for a page, you would use the GET method. The difference is that GET encodes variables as part of the URL for the page being called.
For instance, a news item for April 1st might have a URL like this:
news.php?item=20070401
You would access the value of item in your PHP code by referring to $_GET[item]
We just happen to have a complete working example application, a used book webstore, running over at simpleshop.org which was written in PHP using a MySQL database. Sure, it could use more bells and whistles, but there's enough there to be both a working prototype and a reasonably complete tutorial. (It's due for a serious overhaul, including better use of cascading style sheets; that's a challenge because I don't want it to become overwhelming to people who are still at the "hello, world" level of HTML design.)
This background material should give you a running start with the many PHP books that have recently become available. I like Larry Ullman's Quickstart and Quickpro books, PHP for the World Wide Web; they start out simple but there is enough meat to let you write working applications by the time you get to the end.
If you have prior experience with languages that use "{braces and semicolons};" you will get a lot of mileage out of O'Reilly's PHP Cookbook.
One thing you may notice is that these books make references to object-oriented PHP. I had an "aha!" moment while reading this draft proposal for an object-oriented approach to improving PHP code and avoiding security problems. If you've read PHP books only to have your eyes glaze over at their use of the -> operator, take a look at this article.
Finally, for the whole story on PHP, IBM Developer Works provides a comprehensive page of PHP resources.
