The $_POST variable is used to collect values from a form with method=”post”. Information sent from a form with the POST method is invisible to others and has no limits on the amount of information to send.

The $_POST variable is used to collect values from a form with method=”post”.

The $_POST variable is an array of variable names and values sent by the HTTP POST method.

Example

<form action=”chi1.php” method=”post”>

Enter your name: <input type=”text” name=”name” />

Enter your Dob: <input type=”text” name=”Dob” />

<input type=”OK” />

</form>

The “chi1.php” file can now use the $_POST variable to catch the form data (notice that the names of the form fields will automatically be the ID keys in the $_POST array):

hi <?php echo $_POST["name"]; ?>.<br />

your <?php echo $_POST["Dob"]; ?> how old!

Why make use of $_POST?

A Variables have no length limit

B Variables sent with HTTP POST are not shown in the URL

yet, because the variables are not displayed in the URL, it is not possible to bookmark the page.

The $_REQUEST Variable

The PHP $_REQUEST variable contains the contents of both $_GET, $_POST, and $_COOKIE.

The PHP $_REQUEST variable can be used to get the result from form data sent with both the GET and POST methods.

Example

hi <?php echo $_REQUEST["name"]; ?>.<br />

your <?php echo $_REQUEST["Dob"]; ?> how old!

Setting and reading cookies in PHP is a part of–dare we say it?–cake. We don’t want to get into all the misinformation about cookies, but they’re important and useful. Sometimes they’re the right tool for the work.

create and modify a cookie In PHP

To create and modify a cookie, use the PHP function setcookie(). setcookie() takes up to six arguments, depending upon how much control you want over the cookie and who can read its value.

The best way of setting a cookie is like this:

setcookie(‘name’, ‘xxx’);

Then, for every further page on your site viewed by this browser (without the user quitting) you’ll have the value of ‘xxx’ stored in the variable $name for easy right to use in PHP. This type of cookie is known as a session cookie, since it lasts for the length of a user’s session.

If you want the cookie to persevere after the person exits his or her browser, you must pass setcookie() through a third parameter, the date you want the cookie to expire. Since PHP’s background springs fully formed from the head of Unix, you correspond to this time as the number of seconds since March 23, 1985. If you’re a Unix programmer, this makes total sense. But, if you’re from a Windows or a Macintosh background, you’re just trembling your head wondering if you’ll ever understand those wacky Unix folk.

PHP has a very nice function, mktime(). You pass mktime() (in this order) the hour, minute, second, month, day, and year that you want to represent, and mktime() returns to you the number of seconds since March 1, 1985. So, if you want to simulate a ZZZ meltdown:

<?php

$ZZZ = mktime(0,0,0,1,1,2000);

setcookie(‘name’, ‘xxx’, $ZZZ);

?>

your cookie will end with the millennium.

If you want to update a cookie to store a newer value, you can simply overwrite its value. So, even if you’ve previously sent the cookie above on an earlier page, it’s perfectly legal to go ahead and change your name to “akki.”

<?php

$ZZZ = mktime(0,0,0,1,1,2000);

setcookie(‘name’, ‘akki’, $ZZZ);

?>

Note that doing this doesn’t alter the value of the variable $name. It’s set when the page is loaded. If you want to make sure these two are always in sync, you can code like this:

<?php

$name = ‘Akki’;

$ZZZ = mktime(0,0,0,1,1,2000);

setcookie(‘name’, $name, $ZZZ);

?>

The next two parameters for setcookie() let you control the path and the domain of who can read your cookie. By default, only pages equivalent to or lower down in the ladder on the same server that sends the cookie can read its value. That’s for security’s sake. However, if you had an account that’s sometimes “www.any.com” but also “other.any.com,” and your account lets you serve pages from ~/myhome, you should modify setcookie() as such:

<?php

setcookie(‘name’, ‘akki’, $ZZZ, ‘~/myhome’, ‘.any.com’);

?>

The last parameter to setcookie(), which we’ve never used, teach that the cookie be sent only to a Web server that’s running a secure connection such as SSL. For this to occur, set the sixth value to 1.

Delete Cookie

Deleting a cookie is simple, simply pass setcookie() the name of your cookie and PHP will arrange for it to be deleted.

<?php setcookie(‘name’); ?>

There’s one last important item to cite about using cookies. Because of the way cookies work within HTTP, it’s important that you send all cookies before you print any text. If you don’t, PHP will give you a warning and your cookies will not be sent. So, this is OK:

<?php

setcookie(‘name’, ‘akki’);

echo “Good Morning!”;

?>

But this is not:

<?php

echo “Good Morning!”;

setcookie(‘name’, ‘akki’);

?>

The error handling in PHP is very easy. An error message with filename, line number and a message describing the error are sent to the browser.

When generate scripts and web applications, error handling is an important part. If your code lacks error checking code, your program may look very unethical and you may be open to security risks.

Using the die() function

The first illustration shows a simple script that opens a text file:

<?php

$file=fopen(“chi1.txt”,”c”);

?>

If the file does not exist you might get an error like this:

Advice: fopen(chi1.txt) [function.fopen]: failed to open stream:

No such file or directory in C:\webfolder\test.php on line 2

To avoid that the user gets an error message like the one above, we test if the file exist before we try to access it:

<?php

if(!file_exists(“chi1.txt”))

{

die(“File not found”);

}

else

{

$file=fopen(“chi1.txt”,”c”);

}

?>

Now if the file does not exist you get an error like this:

File not found

The code above is more competent than the earlier code, because it uses a simple error handling device to stop the script after the error.

In PHP session variable is used to store up information about, or modify settings for a user session. Session variables hold information about one single user, and are available to all pages in one application.

Session Variables in PHP

While you are working with an application, you open it, do some modify and then you close it. This is much like a Session. Computer knows when you start the application and when you end. But on the internet there is one problem: the web server does not know who you are and what you do because the HTTP address doesn’t continue state.

A PHP session solves this problem by allowing you to store user information on the server for later use. However, session information is temporary and will be removing after the user has left the website. If you need a enduring storage you may want to store the data in a database.

Sessions work by creating a unique id (UID) for each visitor and store variables based on this UID. The UID is either stored in a cookie or is spread in the URL.

Create a PHP Session

Before you can store user information in your PHP session, you must first start up the session.

Message: The session_start() function must appear ahead of the <html> tag:

<?php session_start(); ?>

<html>

<body>

</body>

</html>

The code above will register the user’s session with the server, allow you to start saving user information, and allot a UID for that user’s session.

Store up a Session Variable

The accurate way to store and retrieve session variables is to use the PHP $_SESSION variable:

<?php

session_start();

// store session data

$_SESSION['xxx']=1;

?>

<html>

<body>

<?php

//retrieve session data

echo “Page=”. $_SESSION['xxx'];

?>

</body>

</html>

Output:

Page=1

In the example under, we make a simple page counter. The isset() function checks if the “xxx” variable has already been set. If “xxx” has been set, we can addition our counter. If “xxx” doesn’t exist, we create a “xxx” variable, and set it to 1:

<?php

session_start();

if(isset($_SESSION['xxx']))

$_SESSION['xxx']=$_SESSION['xxx']+1;

else

$_SESSION['xxx']=1;

echo “Page=”. $_SESSION['xxx'];

?>

Destroying a Session

If you wish to remove some session data, you can use the unset() or the session_destroy() function.

The unset() function is used to free the specified session variable:

<?php

unset($_SESSION['xxx']);

?>

You can also totally destroy the session by calling the session_destroy() function:

<?php

session_destroy();

?>

message: session_destroy() will reset your session and you will lose all your stored session data.

PHP 5 has been a very important release for the language – it has formalized a lot of the features that before had only a little support, or was perhaps distracted. It was also the first version after PHP 4, which was a rebellion in the language, so it had a great deal to live up to. As a major version, PHP 5 has a lifespan of between three and four years – PHP 4 was officially released on 22nd May 2000 and went through many revisions before being replaced by PHP 5 over four years later.

Between now and PHP 6, we will observe several minor patch releases at first that correct many problems with the original PHP 5 release. With PHP 5.1, whenever it is released, we will see the first big set of new functionality – mostly new functions to use, and new ways of doing things. What is certain is that more and more extensions will be added to the system to allow programmers to take advantage of more and more things in their code.

Already confirmed for PHP 5.1 is the PHP Data Objects extension (PDO), which unifies the various database APIs so that you can just call pdo_query() rather than mysql_query(), pgsql_query(), or any of the others. It won’t replace PEAR::DB because it doesn’t abstract the SQL dialects being used, but it will instead complement PEAR::DB. We’re also expecting big speed improvements in PHP 5.1, and not just in any single area – all sorts of calls, from switch/case statements to the sort() function and class autoloading are all improved.

When it comes to what will be in PHP 6, who knows? Many people have asked that PHP be able to compile down into native instructions for maximum speed, which would certainly keep PHP in the lead when it comes to performance, however it would particularly hard to execute. Another possibility is that code caching be built directly into the language so that products such as PHP Accelerator and Zed Performance Suite are no longer necessary – the language could be made to accept caching simply by toggling a switch in php.ini. It is also possible that some features left out from PHP 5 will finally see the light of day in PHP 6, such as namespaces – only time will tell.

Having said that, there are two features I’d particularly like to see in future releases: multiple dispatch and junctions. Multiple dispatches are the technique of calling a given function on several objects at the same time, and if it were in PHP would look something like this:

$array = array($object1, $object2);
$array->doFunc($para1, $para2, $para3);

That would call the doFunc() method of $object1 and $object2, passing in $para1, $para2, and $para3. Junctions – also called quantum superposition by some Perl hackers – is a new feature in Perl 6 that allows you to assign more than one value to a variable then run circumstances like “if $myvar is any of values A, B, C, or D, then…”. Yes, this is already possible with lots of || operators (or && operators if you want to say “$myvar is all of these values…”). Mmmm… quantum superposition!

With PHP continuing to gain massive support from programmers looking to expand their programming horizon, new versions of the language are likely to be geared towards solidifying its position as opposed to revolutionize. When Perl 6 was being intended, many huge changes were brought that separated a lot of developers – hopefully PHP will not go the same way.

In the interim, be happy that you have chosen such a popular language that is advancing so rapidly – PHP is here to stay, and things are only going to get better!