About Packages

Each package is a compressed archive containing product information, program files, icons, documentation and management scripts. Management applications use these files to safely locate, install, update and remove software.

Packages also include a digital signature to prove their source. Software management utilities verify this digital signature by using a GPG public key. The yum and rpm utilities share a common keyring that stores all of the public keys for approved package sources. The system administrator configures these approved package sources.

About Repositories

A repository is a prepared directory or web site that contains software packages and index files. Software management utilities such as yum automatically locate and obtain the correct RPM packages from these repositories. This method frees you from having to manually find and install new applications or updates. You may use a single command to update all system software, or search for new software by specifying criteria.

About Dependencies

Some of the files installed on a distribution are libraries which may provide functions to multiple applications. When an application requires a specific library, the package which contains that library is a dependency. To properly install a package. The dependency information for a RPM package is stored within the RPM file.

The yum utility uses package dependency data to ensure that all of requirements for an application are met during installation. It automatically installs the packages for any dependencies not already present on your system. If a new application has requirements that conflict with existing software, yum aborts without making any changes to your system.

Understanding Package Names

Each package file has a long name that indicates several key pieces of information. This is the full name of the tsclient package supplied with CentOS:

tsclient-0.132-4.i386.rpm

Management utilities commonly refer to packages with one of three formats:

For clarity, yum lists packages in the format name.architecture. Repositories also commonly store packages in separate directories by architecture. In each case, the hardware architecture specified for the package is the minimum type of machine required to use the package.

Thanks to PHP, we can check our email account remotely using PHP and its imap_xxx functions, which allow us to communicate with mail servers via IMAP, POP3 or NNTP protocols. In this article Mitchell shows us how to create a completely web-based email checking script which can also delete, send and reply to emails… all using only PHP’s IMAP functions.How many times have you been away from your home PC and wished that you could check your IMAP/POP3 mail account? If you’re anything like me then you’re always on the move and your laptop is your best friend.

Thanks to PHP, we can check our email account remotely using PHP and its imap_xxx functions, which allow us to communicate with mail servers via IMAP (Internet Message Access Protocol), POP3 (Post Office Protocol) and/or NNTP (Network News Transfer Protocol).

In this article we’re going to build a mail script that will accept an email account, password and optional IMAP port number. The script will then login to that mail account and display the users inbox in a similar fashion to the way Hotmail does: all using only PHP and HTML. From the inbox screen, we have the option to compose a new email, view our emails and even reply to them.

To test the source code and examples in this article you should be running either a Windows/Linux server with IIS/Apache and PHP 4+ installed. You should also have the IMAP libraries installed, which we will look at shortly.

Create Your Own Mail Script With PHP and IMAP - What is IMAP?
(Page 2 of 6 )

IMAP is a method of accessing email messages stored on a remote mail server. The reason IMAP is so popular is because it allows clients to connect to and interact with their mail server without the need to download their emails and files locally. In other words, IMAP allows us to treat a remote mail server as is if it was on our local machine, checking our accounts, manipulating emails, replying to emails, etc.

IMAP shouldn’t be confused with the POP3 protocol, however. If you’ve ever used Outlook or Eudora or any other client mail access program, then you’ll know that you can “check” your email, disconnect from the Internet and your mail will be stored on your local machine, saving you the hassle of being on the ‘net to read your email. This is POP’s biggest advantage: offline access to your email. POP downloads all new messages off the server onto your local PC and then deletes them from that server. IMAP on the other hand queries the server, leaving all emails intact unless you specifically tell it to delete them.

POP was designed for use with client side email applications such as Outlook, whereas IMAP was designed for people on the move, wanting to check their email but not necessarily retrieve it.

The key goals for IMAP are:

• Be fully compatible with Internet messaging standards, e.g. MIME.
• Allow message access and management from more than one computer.
• Allow access without reliance on less efficient file access protocols.
• Provide support for online, offline and disconnected access modes.
• Support for concurrent access to shared mailboxes.
• Client software needs no knowledge about the server’s file store format.

Let’s take the last point into configuration: “Client software needs no knowledge about the server’s file store format”. In my opinion this is one of IMAP’s best features. The client simply queries the mail server using IMAP specific commands and that server returns the data the client’s after.

It doesn’t matter how the server stores the actual email messages (whether it be in a flat file, a MySQL database, an MSSQL server database or any other format) as long as the server returns the data that the client requests, then the storage method and location are irrelevant.

Bringing PHP into the picture

If you’ve worked with PHP extensions then you’ll know that it supports IMAP through an extension library, which isn’t installed by default. Before we can play around with PHP and IMAP, we have to install the necessary IMAP libraries first.

Configuring PHP on Windows with IMAP support

It’s easy to configure your Windows server to work with IMAP. Firstly, grab the php_imap.dll file from your PHP download (it should be in the extensions directory). If you can’t find it then download the PHP zip package here.

Next, copy php_imap.dll to your PHP extension directory, which you can find in your php.ini file as the extension_dir variable. Lastly, open php.ini and look for the line starting “;extension=php_imap.dll”. Remove the semicolon from the front, save the file and restart your web server.

Configuring PHP on Linux with IMAP support

To enable IMAP support on your PHP installation you need to compile PHP with the –with-imap argument. You also need to download the IMAP library here. Once you’ve downloaded it, copy c-client/c-client.a to /usr/local/lib/libc-client.a. Also copy c-client/rfc822.h, mail.h and linkage.h to /usr/local/include or some other directory in your include path.

Testing for IMAP support

To make sure IMAP support is configured correctly, create a new file called phpinfo.php and save it into a directory that your web server can process. Add the following code to it and run it in your web browser:

<?php echo phpinfo(); ?>

Scroll down the page about half way and look for the IMAP section. You should see something like this:

Now that we’ve setup IMAP support, it’s time to take a look at the various IMAP functions that we will be using later in this article to create our email script.

Create Your Own Mail Script With PHP and IMAP - IMAP functions
(Page 3 of 6 )

The IMAP library has 61 functions. Luckily we only need to use a handful of these to create a fully functional email script. The functions we will be using in this article are shown and detailed below:

• imap_open: Opens an IMAP stream to a mailbox.
• imap_headers: Returns headers for all emails in a mailbox.
• imap_headerinfo: Reads the header of an email.
• imap_delete: Mark an email for deletion from current mailbox.
• imap_expunge: Delete all emails marked for deletion.
• imap_mail: Sends an email message to a recipient.
• imap_body: Reads the body of an email from a mailbox.

As mentioned earlier, we’re going to create a script that allows us to check our email account on the move using IMAP. Before we create the script however, let’s start with the basics. Create a new file called testimap.php and enter the following code into it:

<?php

$server = “mail.com”;

$user = “john”;

$pass = “mypass”;

$conn = @imap_open(”\{$server/imap}INBOX”, $user, $pass)

or die(”Connection to server failed”);

?>

Replace the $server variable with the host name of your mail server. Replace $user with your mailbox account name and also replace $pass with the password for your mailbox. To connect to our mail server we use the imap_open function, passing in our mailbox, user ID and password. The format of the mailbox parameter looks like this:

{host_name[:port number]/imap}INBOX

The port number part of the mailbox parameter is optional. If we refer back to the testimap.php file above, our mailbox parameter looks like this:

{mail.com/imap}MAILBOX

In our example we’ve left out the port number. We could’ve optionally specified the port number like this:

{mail.com:25/imap}INBOX

The imap_open function returns an IMAP stream on success and FALSE on failure. We use this returned IMAP stream with various other imap_xxx function calls to manipulate our mailbox, send emails, etc.

To retrieve a list of emails in our mailbox, we can use the following code:

$headers = @imap_headers($conn)

or die(”Couldn’t get emails”);

$numEmails = sizeof($headers);

echo “You have $numEmails in your mailbox”;

In the example above I’ve called the imap_headers function, passing in our IMAP stream as the only parameter. The imap_headers function returns an array of headers. Each of these headers contains the details of one email in our mailbox, and we can use the values of these headers to show who these emails have come from, their subjects, date received, etc. These headers do not however contain the body of each email message, and we must use the imap_body function to get them.

Now that we’ve got an array of headers representing each email in our mailbox, we can loop through them to display the details of each message with the imap_headerinfo function, like this:

for($i = 1; $i < $numEmails+1; $i++)

{

$mailHeader = @imap_headerinfo($conn, $i);

$from = $mailHeader->fromaddress;

$subject = strip_tags($mailHeader->subject);

$date = $mailHeader->date;

echo “Email from $from, subject $subject, date $date<br>”;

}

As you can see from the code above, we use the imap_headerinfo function to get the header details for each message. We extract the from address, subject and date for each message and use the echo command to output them to the browser.

Now that we’ve displayed each message in our mailbox, we can use the imap_close function to close the IMAP stream we created earlier with imap_open:

imap_close($conn);

On this page we’ve taken a look at the basic imap_xxx functions that are required to open an IMAP stream, retrieve headers and display the details of each email from these headers. On the next page we’re going to put everything we’ve learnt so far to good use and create the email script I’ve been mentioning.

Create Your Own Mail Script With PHP and IMAP - Creating our email script
(Page 4 of 6 )

There are a huge number of email applications on the market, however most of them expose the same core functionality:

• You can check your mailbox on any mail server.
• You can create and send emails.
• You can reply to emails.
• You can delete emails from your mailbox.

The script we’re about to discuss implements each of the bullet points shown above. We will run through the code step by step, describing various function calls where necessary.

Our script contains several functions and a switch statement. The switch statement works with the $what variable, which can be either a query string or form posted variable. Each time our script is called, a different function is executed, depending on the value of $what:

switch($what)

{

case “login”:

ProcessLogin();

break;

case “inbox”:

ShowInbox();

break;

case “delete”:

DeleteEmails();

break;

case “compose”:

ShowComposeForm();

break;

case “send”:

SendMessage($to, $subject, $message, $cc, $bcc);

break;

case “read”:

ShowEmail();

break;

case “reply”:

ShowComposeForm($to, $subject, $message);

break;

default:

ShowLoginForm();

}

As you can see, the default option calls the ShowLoginForm function, which allows us to enter our email address and password. The ShowLoginForm function simply displays a HTML form which includes a hidden form variable, $what, which is set to “login”.

The ProcessLogin function is called when $what is equal to “login”. It validates the email address from the login form using the ereg function and creates some session variables containing our mailbox, username, host and password:

$validEmail = ereg(”^([a-zA-Z0-9_\-\.]+)@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.)|(([a-zA-Z0-9\-]+\.)+))([a-zA-Z]{2,4}|[0-9]{1,3})(\]?)$”, $email);

$validPass = ($password == “” ? false: true);

$portString = (is_numeric($port) == true ? “:$port” : “”);

if(!$validEmail || !$validPass)

{

// Email or password are bad

die(”<h2>Invalid Login Credentials</h2>”);

}

else

{

// Email and password are fine, get the user and hosts

$arr = split(”@”, $email);

$user = $arr[0];

$host = $arr[1];

$mailbox = “\{$host$portString/imap}INBOX”;

// Set the login credentials as session variables

setcookie(”mailbox”, $mailbox);

setcookie(”user”, $user);

setcookie(”host”, $host);

setcookie(”password”, $password);

header(”Location: $PHP_SELF?what=inbox”);

}

As you can see, we use the split function to separate the users email address into the $user and $host variables. We also create the $mailbox variable from the host name and port number, which may or may not be specified in the login form. The user is then redirected to the same scripting using $PHP_SELF, passing “inbox” as the $what query string variable. This results in the ShowInbox function being called.

The ShowInbox function connects to our mail server using imap_open (which we saw in our first example) and retrieves the headers for each email message in our mailbox. These headers are then extracted into variables and a HTML table is created that lists the details of each email. Each email is also hyper linked to the script, setting the query variables $what to “read”, and $id to the ID of the email, which is the index of that particular email in the array returned from a call to imap_headers:

<td width=”50%”>

<a href=”<?php echo $PHP_SELF; ?>?what=read&id=<?php echo $i; ?>”>

<?php echo $subject; ?>

</a>

</td>

When $what is “read”, the ShowEmail function is called.

Create Your Own Mail Script With PHP and IMAP - The ShowEmail function and more
(Page 5 of 6 )

ShowEmail connects to our IMAP server using imap_open and retrieves both the header and body details of one specific email. As we saw earlier, imap_headerinfo returns the header details of an email as an array, like this:

$mailHeader = @imap_headerinfo($conn, $id);

…

$from = $mailHeader->fromaddress;

$subject = strip_tags($mailHeader->subject);

$date = $mailHeader->date;

The body of the email is then retrieved with a call to imap_body. Because our email script only displays plain text emails, we use strip_tags to remove all HTML formatting from the email:

$body = nl2br(strip_tags(imap_body($conn, $id)));

We then output all of these details to a form, including a button that lets us reply to this specific email:

<form name=”frmLogin” action=”<?php echo $PHP_SELF; ?>” method=”post”>

<input type=”hidden” name=”what” value=”reply”>

<input type=”hidden” name=”to” value=”<?php echo $from; ?>”>

<input type=”hidden” name=”subject” value=”Re: <?php echo $subject; ?>”>

<input type=”hidden” name=”message” value=”<?php echo str_replace(”<br />”, “”, str_replace(”\r\n”, “\r\n>>”, $body)) ?>”>

<h2><?php echo $subject; ?></h2>

<hr noshade size=”1″ color=”#20158F”>

<b>From:</b> <?php echo str_replace(”<”, “&lt;”, $from); ?><br>

<b>Date:</b> <?php echo $date; ?><br>

<hr noshade size=”1″ color=”#20158F”>

<?php echo $body; ?>

<hr noshade size=”1″ color=”#20158F”>

<input type=”submit” name=”submit” value=”Reply >>”>

</form>

As you can see, this form passes the value “reply” for the hidden form variable “what”. The to, subject and message fields are also passed as hidden form variables, which in turn calls the ShowComposeForm function, which displays a HTML form in exactly the same was as the ShowEmail function.

Although this might sound a little confusing, the ShowComposeForm function is also used to compose a new email. The parameters passed to the function are the values for each text box in the form: if we don’t pass any parameters then we’re creating a new form. If we do, then we’re replying to a message. Here’s the function signature of ShowComposeForm:

function ShowComposeForm($to = “”, $subject = “”, $message = “”)

The ShowComposeForm function includes a hidden form variable, what, which is set to “send”, triggering a call to the SendMessage function when the form is submitted.

The function signature of SendMessage looks like this:

SendMessage($to, $subject, $message, $cc, $bcc);

SendMessage uses the imap_open function to connect to our mail server. If the connection was successful, it then uses imap_mail to send an email message to the intended recipient, like this:

imap_mail($to, $subject, $message, “From: $user@$host”, $cc, $bcc);

One last function that I will mention is our DeleteEmails function. This function calls imap_delete as well as imap_explunge to remove email messages from our mailbox based on their ID. The ID’s for the DeleteEmails function are passed as an array from the form generated by the ShowInbox function:

for($i = 1; $i < $numEmails+1; $i++)

…

<td width=”5%”">

<input type=”checkbox” name=”emails[]” value=”<?php echo $i; ?>”>

</td>

The imap_delete function accepts two parameters: an IMAP stream object and the ID of the email to delete:

for($i = 0; $i < sizeof($emails); $i++)

{

@imap_delete($conn, (int)$emails[$i]);

}

Once we’ve called imap_delete for each email, we must call the imap_expuge function to actually remove the messages from the server:

@imap_expunge($conn);

]]> http://webtechnology.wordpress.com/2008/05/26/create-your-own-mail-script-with-php-and-imap/feed/ aseefahmed Making sure IMAP was configured OK http://webtechnology.wordpress.com/2008/04/23/retrieving-data-in-cakephp/ http://webtechnology.wordpress.com/2008/04/23/retrieving-data-in-cakephp/#comments Wed, 23 Apr 2008 06:51:24 +0000 aseefahmed http://webtechnology.wordpress.com/?p=41

Sample model - note the $actsAs

To change default settings do:
Download code
var $actsAs = array(’transaction’ => array(’keyName’ => ‘value’) );


Model Class:

Download code <?php
class Order extends AppModel
{
var $name = ‘Order’;
var $actsAs = array(‘transaction’);
var $hasMany = array(‘OrderDetail’);
?>

Controller Class:

Download code <?php
class OrderController extends AppController {
var $name = ‘Order’;
var $uses = array(‘Order’);

function checkout() {
if(!empty($this->data)) {
$this->Order->begin(); // Start our transaction
if( $this->Order->save( $this->data ) ) {
if( $this->Order->OrderDetail->save( $this->data ) ) {
$this->Order->commit(); // Persist the data
$this->redirect(‘/shop/order/thanks’);
exit;
} else {
// Couldnt save the products to the order
// since the products to the order couldnt be stored, dont store anything at all
// rollback all changes to the database sine ‘begin’ was called
$this->Order->rollback();
$this->redirect(‘/shop/order/error’);
exit;
}
} else {
// Didnt save
}
}
}
}
?>

Model Class:

Download code <?php
/**
* Transaction support for models in 1.2
*
* @version 0.2
* @author Christian ‘Jippi’ Winther
*/
class TransactionBehavior extends ModelBehavior {
/**
* Settings: (false will disable them)
*
* - autocommit_on_start [ false | 0 | 1 ]
* Disable auto-commit on start?
*
* - autocommit_after_commit [ false | 0 | 1 ]
* Set auto-commit after successfull commit
*
* - autocommit_after_rollback [ false | 0 | 1 ]
* Set auto-commit after successfull rollback
*
* - throw_error [ false | true ]
* Should we call user_error if something is wrong?
*
* - error_level [ E_USER_* constants ]
* What level should the user_error use?
*
* - configure_key [ string ]
* What key should the transaction state be stored as
*
* @version 0.1
* @since 0.1
* @access private
* @var array
*/
var $settings = array(
‘autocommit_on_start’ => false,
‘autocommit_after_commit’ => 1,
‘autocommit_after_rollback’ => 1,
‘throw_error’ => false,
‘error_level’ => E_USER_NOTICE,
‘configure_key’ => ‘inTransaction’
);

/**
* List of legal ‘locks’
*
* @version 0.1
* @since 0.1
* @access private
* @var array
*/
var $validLocks = array(‘read’,‘write’);

/**
* Startup hook from the model
*
* @version 0.1
* @since 0.1
* @access public
* @param AppModel $model
* @param array $config
*/
function setup(&$model, $config = array()) {
/**
* Check if there has been set a transaction state in another model
* Configure::read returns null if no value is found, so its safe to
* set the default value for our transaction state ( false )
*/
if( is_null( $this->_getTransactionState() ) ) {
$this->_setTransactionState( false );
}

/**
* If there was given any config settings to this behavior, merge them
* with our default settings array
*/
if( !is_null( $config ) && is_array( $config ) ) {
$this->settings = array_merge( $this->settings, $config );
}

/**
* If we wish to start an transaction at load time do so
*/
if( $this->settings['autocommit_on_start'] !== false ) {
$this->begin( $model );
}
}

/**
* Begin a database transaction
*
* @version 0.1
* @since 0.1
* @access public
* @param AppModel $model
* @param int $autocmmit
* @return boolean
*/
function begin( &$model, $args = array()) {
if( $this->_getTransactionState() === false ) {
$this->_setTransactionState( true );
$model->query(‘SET autocommit=0′);
$model->query(‘begin’);
return true;
}
$this->_error(‘Transaction has already started’);
return false;
}

/**
* Commits a database transaction
*
* @version 0.1
* @since 0.1
* @access public
* @param AppModel $model
* @param integer $autocommit
* @return boolean
*/
function commit( &$model, $args = array() ) {
if( $this->_getTransactionState() === true ) {
$this->_setTransactionState( false );

$autoCommit = empty($args[0]) ? $this->settings['autocommit_after_commit'] : $args[0];
$model->query(‘commit’);
if( $autoCommit !== false ) {
$model->query(‘SET autocommit=’. $autoCommit);
}
return true;
}
$this->_error(‘No transaction active’);
return false;
}

/**
* Rollback a transaction
*
* @version 0.1
* @since 0.1
* @access public
* @param AppModel $model
* @param integer $autocommit
*/
function rollback( &$model, $args ) {
if( $this->_getTransactionState === true ) {
$this->_setTransactionState( false );
$model->query(‘rollback’);
$autoCommit = empty($args[0]) ? $this->settings['autocommit_after_rollback'] : $args[0];
if( $autoCommit !== false ) {
$model->query(‘SET autocommit=’. $autoCommit);
}
return true;
}
$this->_error(‘No transaction active’);
return false;
}

/**
* Locks the model table for either READ or WRITE
*
* - Arg[0] is either ‘READ’ or ‘WRITE’
* - Arg[1]:
* If null : Its going to lock the model table
* If string : Locking the given table
* If array : Going to lock all tables specified
* NOTE: You have to specify model table aswell!
*
* @version 0.2
* @since 0.1
* @access public
* @param AppModel $model
* @param array $args
*/
function lockTable( &$model, $args = array( ) ) {
$type = strtolower( empty( $args[0] ) ? null : $args[0] );
$table = strtolower( empty( $args[1] ) ? $model->table : $args[1] );
if( is_null( $type ) ) {
$this->_error(‘Missing parameter for lockTable(), either READ or WRITE’);
return false;
}
if( array_search( $type, $this->validLocks ) !== false ) {
if(is_array($table)) {
$res = array();
foreach ( $table AS $tableName ) {
$res[ $tableName ] = $model->query(‘LOCK TABLE ‘.$table.‘ ‘. strtoupper($type));
}
return $res;
} else {
$model->query(‘LOCK TABLE ‘.$table.‘ ‘. strtoupper($type));
return true;
}
}
return false;
}

/**
* Remove all locks made on tables
*
* @version 0.1
* @since 0.1
* @access public
* @param AppModel $model
* @param array $args
*/
function unlockTable( &$model, $args = array() ) {
$model->query(‘UNLOCK TABLES’);
}

/**
* Show an error to screen (When debug > 0 )
*
* @version 0.1
* @since 0.1
* @access private
* @param string $string
*/
function _error( $string ) {
if( $this->settings['throw_error'] ) {
trigger_error($string, $this->settings['error_level'] );
}
}

/**
* Get the current transaction state
*
* @version 0.1
* @since 0.1
* @access private
* @return boolean
*/
function _getTransactionState() {
return Configure::read( $this->settings['configure_key'] );
}

/**
* Write a new transaction state
*
* @version 0.1
* @since 0.1
* @access private
* @param boolean $value
*/
function _setTransactionState( $value ) {
if( is_bool( $value ) ) {
Configure::write( $this->settings['configure_key'], $value );
}
$this->_error(‘Not valid transaction state’);
}
}
?>

Creating reusable elements with requestAction is very simple. At the end, we can even cache the element using the new feature in 1.2.

Start of with a simple controller.

Controller Class:

Download code <?php
class PostsController extends AppController {
var $name = ‘Posts’;

function index() {
$posts = $this->Post->findAll();
if(isset($this->params['requested'])) {
return $posts;
}
$this->set(‘posts’, $posts);
}
}
?>
So, we created the Posts controller and we gave it an index action. Then we found all the posts, then if requestAction is used it will return the posts, otherwise it will set the posts for the view.

Now we can create a reusable element that will use requestAction. We create a file in /app/elements/posts.thtml, then add the code below.

View Template:

Download code
$posts = $this->requestAction(’posts/index’);
foreach($posts as $post):
echo $post['Post']['title'];
endforeach;


Now we have the element we can include it in the layout, another element or a view template.

View Template:

Download code
<?php echo $this->renderElement(‘posts’);?>


The code above is for 1.1. If you want to get into the goodness of Cake 1.2 you can look at the updated code below.

Controller Class:

Download code <?php
class PostsController extends AppController {
var $name = ‘Posts’;

function index() {
$posts = $this->paginate();
if(isset($this->params['requested'])) {
return $posts;
}
$this->set(‘posts’, $posts);
}
}
?>
Notice we changed the index action to use paginate instead.
In the view we can use paginate params to control what is returned.

View Template:

Download code
$posts = $this->requestAction(’posts/index/sort:created/direction:desc/limit:10′);
foreach($posts as $post):
echo $post['Post']['title'];
endforeach;

Now we are only grabbing the latest 10 posts. Whoa, we just created a latest posts element without having to change our index action or create another action.

Lets call this one latest posts and cache it for an hour.
create the file /app/elements/latest_posts.ctp.

View Template:

Download code
<?php echo $this->element(‘latest_posts’, array(‘cache’=>‘+1 hour’);?>

We can still use this element in any other view file.

There are other ways to use requestAction, but if you are looking to create reusable elements for your site, then this is the way to go.

On its 1.1 release, CakePHP only allowed us to define one rule of validation per field. If we needed to specify more than one rule, we either had to use some handy extensions to CakePHP that are available, or achieve multiple validation by using the callback method beforeValidate() in our models. CakePHP 1.2 brings us an improved technique to specify multiple rules per field, and best of all, it’s backwards compatible, so our existing rules will continue to work.

What better way to start that with an example, specifically the typical Article CRUD example. We start by creating a simple controller that provide us with an add form:

Controller Class:

Download code <?php
class ArticlesController extends AppController {
var $name = ‘Articles’;
var $helpers = array(‘Form’);

function add() {
if (!empty($this->data)) {
// We don’t do any real saving, we just validate the model

if ($this->Article->create($this->data) && $this->Article->validates()) {
$this->set(‘valid’, true);
}
}
}
}
?>

and its matching articles/add.ctp view:

View Template:

Download code
<?php echo $form->create(‘Article’); ?>
<?php echo $form->input(‘title’); ?>
<?php echo $form->input(‘body’); ?>
<?php echo $form->end(‘Add Article’); ?>


Let’s take the classic Article model, and add only one validation to some fields:

Model Class:

Download code <?php
class Article extends AppModel {
var $name = ‘Article’;
var $validate = array(
‘title’ => VALID_NOT_EMPTY,
‘body’ => VALID_NOT_EMPTY
);
}
?>

Nothing new here, except that as you can see we’re not defining the error messages. We are going to do so in the view. So we go back and change the add.ctp view so it now looks like this:

View Template:

Download code
<?php echo $form->create(‘Article’); ?>
<?php echo $form->input(‘title’, array(‘error’ => ‘Please specify a valid title’)); ?>
<?php echo $form->input(‘body’, array(‘error’ => ‘Please specify a valid body’)); ?>
<?php echo $form->end(‘Add Article’); ?>


If we try the add action and submit the form with both fields empty, we’ll get our newly defined error messages. What if we also wanted to add another rule of validation for the title field, where we should check that the title is at the most 100 characters long? Let’s review the model, and now change it to look like this:

Model Class:

Download code <?php
class Article extends AppModel {
var $name = ‘Article’;
var $validate = array(
‘title’ => array(
VALID_NOT_EMPTY,
array(
‘rule’ => array(‘maxLength’, 100)
)
),
‘body’ => VALID_NOT_EMPTY
);
}
?>

We have just converted the ‘title’ field to consist of an array of rules. The first rule is a CakePHP provided regular expression that checks for a specified value, and the second rule is a method existing in CakePHP’s built in Validation class called ‘maxLength’. Since this method takes an extra parameter (the number of maximum characters the field can contain), we add it on an array.

So we have now two conditions that can generate an error for the field title: an empty value, or a value with more than 100 characters. How do we differentiate the error messages on the view? Let’s change the view so it now looks like:

View Template:

Download code
<?php echo $form->create(‘Article’); ?>
<?php echo $form->input(‘title’, array(‘error’ => array(
0 => ‘Please specify a valid title’,
1 => ‘The title must have no more than 100 characters’
))); ?>
<?php echo $form->input(‘body’, array(‘error’ => ‘Please specify a valid body’)); ?>
<?php echo $form->end(‘Add Article’); ?>


As you can see we’re setting an error message per rule. 0 corresponds to the first rule, 1 to the second, and so on. If we wanted more flexibility (such as having the option to change the order of the rules and still have the same error message assignment) and needed more readability, we can then use the string index approach. Change the model so it now looks like:

Model Class:

Download code <?php
class Article extends AppModel {
var $name = ‘Article’;
var $validate = array(
‘title’ => array(
‘required’ => VALID_NOT_EMPTY,
‘length’ => array( ‘rule’ => array(‘maxLength’, 100) )
),
‘body’ => VALID_NOT_EMPTY
);
}
?>

and change the view so it now looks like:

View Template:

Download code
<?php echo $form->create(‘Article’); ?>
<?php echo $form->input(‘title’, array(‘error’ => array(
‘required’ => ‘Please specify a valid title’,
‘length’ => ‘The title must have no more than 100 characters’
))); ?>
<?php echo $form->input(‘body’, array(‘error’ => ‘Please specify a valid body’)); ?>
<?php echo $form->end(‘Add Article’); ?>


Custom Validation

What about custom validation? What if we needed more rules than those provided by CakePHP’s Validation class? Don’t sweat, it comes very easy! All you need to do is set up your own validation functions on either your model or your AppModel class (if you wish to share them across your models.) For example, we’re going to add a new validation rule to allow us to specify a minimum and a maximum length for our title. I know, what’s the point when we have both minLength and maxLength in CakePHP’s Validation class? Well, to show how it can be done

Edit the model and change it so it now looks like this:

Model Class:

Download code <?php
class Article extends AppModel {
var $name = ‘Article’;
var $validate = array(
‘title’ => array(
‘required’ => VALID_NOT_EMPTY,
‘length’ => array( ‘rule’ => ‘validateLength’, ‘min’ => 5, ‘max’ => 100 )
),
‘body’ => VALID_NOT_EMPTY
);

function validateLength($value, $params = array()) {
$valid = false;

$params = am(array(
‘min’ => null,
‘max’ => null,
), $params);

if (empty($params['min']) || empty($params['max'])) {
$valid = false;
} else if (strlen($value) >= $params['min'] && strlen($value) <= $params['max']) {
$valid = true;
}

return $valid;
}
}
?>

A custom validation function takes one mandatory first parameter: the value to validate, and must return a boolean value of true when the value validates, or false when it doesn’t. Extra parameters will be sent to the validation function as an array through its second parameter, and the values in the array are those values specified in the validation rule that do not correspond to CakePHP’s internal values (such as rule or allowEmpty.)

cd changes derectories

• cd 
  • To your home directory

• cd ..
  • To your home directory
• cd -
  • To your previous working directory

Listing Directory Contents

• ls -a 
  • include hidden files

• ls -l
  • long listing style
• ls -R
  • Recurse through directories

Copying Files & Directories

• cp -i source destination
  • interactive(ask before overwriting file)

• cp -R source destination
  • recursive (recursively copy an entire directory tree)

Creating & Removing Files

• touch 
  • create empty file or update filetimestamps

• rm -i 
  • interactive(ask before removing file)
• rm -R
  • recursively (for removing an entire directory)
• rm -f
  • remove by forcing
• mkdir -p
  • make parent directories if needed

What are permissions?

On a UNIX web server, every single file and folder stored on the hard drive has a set of permissions associated with it, which says who is allowed to do what with the file. Every file (and folder) also has an “owner” and a “group” associated with it. If you created the file, then you are usually the owner of that file, and your group, or the group associated with the folder you created the file in, will usually be associated with that file.

Who can do stuff?

There are three types of people that can do stuff to files - the Owner of the file, anyone in the Group that the file belongs to, and Others (everyone else). In UNIX, these 3 types of people are referred to using the letters U (for Owner, or User in UNIX-speak!), G (for Group), and O (for Others).

What stuff can you do?

There are three basic things that can be done to files or folders:

• You can read the file. For folders, this means listing the contents of the folder.
• You can write to (change) the file. For folders, this means creating and deleting files in the folder.
• You can execute (run) the file, if it’s a program or script. For folders, this means accessing files in the folder.

What do all these funny letters and numbers mean?!

That’s the basics of permissions covered. As you can see, there’s not much to them really!

The confusion often occurs when you have to start actually setting permissions on your file server. CGI scripts will tell you to do things like “chmod 755″ or “Check that the file is executable”. Also, when you use FTP or SSH, you’ll see lots of funny letters next to the files (such as rwxrw-rw-). We’ll now explain what all these hieroglyphics mean!

When you FTP to your web server, you’ll probably see something like this next to every file and folder:

This string of letters, drwxrwxrwx, represents the permissions that are set for this folder. (Note that these are often called attributes by FTP programs.) Let’s explain what each of these letters means:

As you can see, the string of letters breaks down into 3 sections of 3 letters each, representing each of the types of users (the owner, members of the group, and everyone else). There is also a “d” attribute on the left, which tells us if this is a file or a directory (folder).

If any of these letters is replaced with a hyphen (-), it means that permission is not granted. For example:

drwxr-xr-x

A folder which has read, write and execute permissions for the owner, but only read and execute permissions for the group and for other users.

-rw-rw-rw-

A file that can be read and written by anyone, but not executed at all.

-rw-r--r--

A file that can be read and written by the user, but only read by the group and everyone else.

Using numbers instead of letters

As we said earlier, you’ll often be asked to do things using numbers, such as “set 755 permissions”. What do those numbers mean?

Well, each of the three numbers corresponds to each of the three sections of letters we referred to earlier. In other words, the first number determines the owner permissions, the second number determines the group permissions, and the third number determines the other permissions.

Each number can have one of eight values ranging from 0 to 7. Each value corresponds to a certain setting of the read, write and execute permissions, as explained in this table:

Read: 4
Write: 2
Execute: 1

So, for example: