
Instead of
focusing on ColdFusion this month, as I have done in the past,
I thought that it would be fun to delve into the “other” language
that I support on web2.unt.edu.
That language PHP, which stands for “PHP: Hypertext Processor”, is
a popular open-source scripting language that is used by many
developers around the world. (See the list in “For More Information”
for sites that are using PHP.) This scripting language has been a
wonderful addition to our dynamic web server, and many of you are
taking advantage of its ease and power.
PHP, Here We Go...
To get
started, I would like to mention some of the great applications that
have been written in PHP.
The
first is our very own EagleMail
application. This application is a variation on the IMP Webmail
Client, which is available at the URL below, and which has been
modified to become a great addition to the University of North Texas
student communication system. This application allows students and
staff to login to check there e-mail from any browser in the world.
The stability of the application is seen as thousands of students
check and respond to e-mail daily through this interface.
The
second example, is an application that many of the web developers on
my server are familiar with. This is PHPMyAdmin. This application is a
web-based front-end for a MySQL database server, which is housed on
one of my servers, and allows a user with the correct rights to
administer their database from any browser in the world. As I have
been supporting databases in a production environment for over 3 years
now, I feel that I am fairly comfortable with a variety of database
server/client interfaces. PHPMyAdmin takes the cake. It is not only
easy to use, but it locks users down to the appropriate level of
security, and allows me, the superuser, to administer everything from
this single interface. (It has even replaced Microsoft Enterprise
Manager for my favorite database administration tool. More
information and a download can be found at the URL below.
The
final application that I would like to mention is a shopping cart
called osCommerce. This application not only has a complete user
shopping cart on the front-end, but it incorporates a wonderful
administrative interface as well. With the ability to include/exclude
payment types, modify/add categories, monitor orders, osCommerce is a
complete e-business solution for any company.
And Now for the Fun...
To initiate the newcomers
to PHP, and to bring the old timers up-to-date, I feel that I should
cover a basic issue that will need to be addressed in all PHP
applications in the future. This is the creating and accessing of
variables using PHP.
In the
past, PHP3 and earlier, web developers were able to pass variables
from page to page with ease. For example:
<FORM
ACTION="firstApp2.php" METHOD="post">
<P><FONT
SIZE=3><B> Please enter your name here:
<INPUT
TYPE=TEXT NAME="NAME"
SIZE=25></B></FONT></P>
<P><FONT
SIZE=3><B> Please enter your telephone here:
<INPUT
TYPE=TEXT NAME="TELEPHONE"
SIZE=25></B></FONT></P>
</FORM>
Would
place the variables NAME and TELEPHONE in memory to be accessed from
“firstApp2.php”. To access these variables from “firstApp2.php”,
you would write the following code:
<p
align="left">__________________________________________________________________</p>
<p
align="left">name: </p><H2> <? print
"$NAME\n"; ?> </H2>
<p
align="left">telephone: </p><H2> <? print
"$TELEPHONE\n"; ?> </H2>
<p
align="left">__________________________________________________________________</p>
First, notice the syntax.
Is it hard to see? A little, because there is not much difference
between the HTML and PHP coding style. (Even more, or less, confusing
for those of you that have done some ASP coding, or a little
JavaScript.) PHP was designed in this way. The creators wanted to make
it easier for someone that has coded in some of these other scripting
languages to be able to write PHP code with minimal difficulty. (They
also wanted to pull some users away from the behemoth Microsoft too!
;) ) Here is a breakdown of what you see.
-
<? ?> -- These
signify that the code found in between these symbols are PHP. The
web server sees this, and send the code to the PHP engine, which
then returns the code to the web server and then the browser.
-
Print – a function
that prints text to a specified location.
-
$NAME – a variable
name. A variable is signified by placing a “$” in front of the
name of the form object on the originating page.
-
\n – a new-line
character. (Acts like a carriage return.)
-
; -- line termination
character. This is VERY IMPORTANT,
as the omission of this character
will cause problems when the code is compiled.
-
“string\n”
-- the quotes designate a string, and the PHP engine will generate
the code as such.
As some may notice, the
syntax is very close to that of Perl, another favorite open-source
language. This is also on purpose. It seems to me that web developers
that have done some programming in the past are drawn to PHP, because
of the ease with which they may transfer code and concepts from their
previous languages. (In my experience, this tends to make for a more
complete and stable range of available applications. Check out HotScripts.com
for a wide range of available PHP applications.)
As you can see, this is
very simple, and as with all simple things, there are some problems
that have become apparent to PHP developers through the maturation of
the product. This is that there is no scope designation for the
variables that were created. This was by design originally. The PHP
engine was supposed to guess the scope of the variable, and guess it
correctly. As you all know, there are those people that like to find
ways of working around things to their advantages, so PHP has had to
come up with a different way of specifying the scope of variables, and
in particular, global variables. (Scope is the realm within which a
variable name's value can be accessed. See the URL below for more
information about scope.)
Recommendations from PHP...
To
help keep an end-user from “poisoning” the variables in your
application, PHP implemented “predefined variables” to help
specify the scope of a variable. Here is the example above, with the
recommended syntax from PHP.
<FORM
ACTION="firstApp2.php" METHOD="post">
<P><FONT
SIZE=3><B> Please enter your name here:
<INPUT
TYPE=TEXT NAME="NAME"
SIZE=25></B></FONT></P>
<P><FONT
SIZE=3><B> Please enter your telephone here:
<INPUT
TYPE=TEXT NAME="TELEPHONE"
SIZE=25></B></FONT></P>
</FORM>
The
first page would remain the same. You will notice the modified code in
the second page though.
<p
align="left">__________________________________________________________________</p>
<p
align="left">name: </p><H2> <? print
"$_POST['NAME']\n"; ?> </H2>
<p
align="left">telephone: </p><H2> <? print
"_POST['$TELEPHONE']\n"; ?> </H2>
<p
align="left">__________________________________________________________________</p>
Or in its simplest form:
<?
print "$_POST['NAME']\n"; ?>
As you
can see, the code is not that complicated, but does force you to
understand the process of accessing variables. If you notice, in the
<FORM> tag on firstApp.php, you see that the METHOD that we have
specified is “post”. That means that we are moving the variable to
an address in memory, instead of in the URL, as a “get” method
would do. Therefore, we choose “$_POST” from our list of “predefined
variables”. This “predefined variable” knows that it needs to
look in memory for the value found in the array of posted form object
values. Hence, the syntax of “$_POST['$variable_name']”. It is
actually pulling the value from the “superglobal_arrays”.
Why am I telling you this?
As
many of you know, we have had some issues with our local installation
of PHP ignoring the register_globals switch, which mimicked a
safe_mode=on type installation. This caused some PHP applications to
fail over about a two day period, until I worked my “can of the Fonz”
on it, and got it to work. What many of you don't know, is that PHP
has been recommending the syntax of the second example above for over
a year now, and is deprecating the syntax of the first example.
(Meaning that it will not be supported by PHP at some point in the
future.) Therefore, to be safe, in the sense of prolonging the life of
your PHP applications and in the sense of making it more difficult for
end-users to poison the variables in your application, it would be
advised that you begin to update your applications to reflect the
accepted syntax of the PHP creators, and the advise of web developers
around the world.
Have a
good one :)
For More Information...
|