Most interactive applications have the ability for users to login and logout. Obvious, right? Laravel provides a simple class to help you validate user credentials and retrieve information about the current user of your application.
The quickest way to get started is to create an [Eloquent User model](/docs/database/eloquent) in your **application/models** directory:
class User extends Eloquent {}
Next, you will need to define **email** and **password** columns on your user database table. The password column should hold 60 alpha-numeric characters. The Auth class **requires** that all passwords be hashed and salted.
> **Note:** The password column on your user table must really be named "password".
Great job! You're ready to start using the Auth class. However, there are more advanced configuration options available if you wish to use them.
Let's dig into the **application/config/auth.php** file. In this file you will find two closures: **by\_id** and **by\_username**:
'by_id' => function($id)
{
return User::find($id);
}
The **by_id** function is called when the Auth class needs to retrieve a user by their primary key. As you can see, the default implementation of this function uses an "User" Eloquent model to retrieve the user by ID. However, if you are not using Eloquent, you are free to modify this function to meet the needs of your application.
The **by_username** function is called when the Auth class needs to retrieve a user by their username, such as when using the **login** method. The default implementation of this function uses an "User" Eloquent model to retrieve the user by e-mail address. However, if you are not using Eloquent or do not wish to use e-mail addresses as usernames, you are free to modify this function as you wish as long as you return an object with **password** and **id** properties.
> **Note:** Before using the Auth class, you must [specify a session driver](/docs/session/config).
<aname="hash"></a>
### Salting & Hashing
If you are using the Auth class, Laravel requires all passwords to be hashed and salted. Web development must be done responsibly. Salted, hashed passwords make a rainbow table attack against your user's passwords impractical.
Don't worry, salting and hashing passwords is easy using the **Hash** class. The Hash class provides a simple way to hash passwords using the **bcrypt** hashing algorithm. Check out this example:
$password = Hash::make('secret');
The **make** method of the Hash class will return a 60 character hashed string.
You can compare an unhashed value against a hashed one using the **check** method on the **Hash** class:
if (Hash::check('secret', $hashed_value))
{
return 'The password is valid!';
}
> **Note:** Before using the Auth class, be sure to [create the "password" column](/docs/auth/config) on your user table.
<aname="login"></a>
### Logging In
Logging a user into your application is simple using the **login** method on the Auth class. Simply pass the username and password of the user to the method. The login method will return **true** if the credentials are valid. Otherwise, **false** will be returned:
if (Auth::login('example@gmail.com', 'password'))
{
return Redirect::to('user/profile');
}
If the user's credentials are valid, the user ID will be stored in the session and the user will be considered "logged in" on subsequent requests to your application.
To determine if the user of your application is logged in, call the **check** method:
if (Auth::check())
{
return "You're logged in!";
}
<aname="filter"></a>
### Protecting Routes
It is common to limit access to certain routes only to logged in users. It's a breeze in Laravel using the built-in [auth filter](/docs/start/routes#filters). If the user is logged in, the request will proceed as normal; however, if the user is not logged in, they will be redirected to the "login" [named route](/docs/start/routes#named).
To protect a route, simply attach the **auth** filter:
Imagine your application displays the ten most popular songs as voted on by your users. Do you really need to look up these ten songs every time someone visits your site? What if you could store them for 10 minutes, or even an hour, allowing you to dramatically speed up your application? Caching makes it simple.
Laravel provides three wonderful cache drivers out of the box:
- File System
- Memcached
- APC
By default, Laravel is configured to use the **file** system cache driver. It's ready to go. The file system driver stores cached items as files in the **application/storage/cache** directory. If you're satisfied with this driver, no other configuration is required. You're ready to start using it.
> **Note:** Before using the file system cache driver, make sure your **application/storage/cache** directory is writeable.
<aname="memcached"></a>
### Memcached
[Memcached](http://memcached.org) is an ultra-fast, open-source distributed memory object caching system used by sites such as Wikipedia and Facebook. Before using Laravel's Memcached driver, you will need to install and configure Memcached and the PHP Memcache extension on your server.
Once Memcached is installed on your server, configuring the Laravel driver is a breeze. First, set the **driver** in the **application/config/cache.php** file:
'driver' => 'memcached'
Next, add your Memcached servers to the **servers** array:
To avoid naming collisions with other applications using APC or a Memcached server, Laravel prepends a **key** to each item stored in the cache using these drivers. Feel free to change this value:
Storing items in the cache is simple. Simply call the **put** method on the Cache class:
Cache::put('name', 'Taylor', 10);
The first parameter is the **key** to the cache item. You will use this key to retrieve the item from the cache. The second parameter is the **value** of the item. The third parameter is the number of **minutes** you want the item to be cached.
> **Note:** It is not necessary to serialize objects when storing them in the cache.
<aname="get"></a>
### Retrieving Items
Retrieving items from the cache is even more simple than storing them. It is done using the **get** method. Just mention the key of the item you wish to retrieve:
$name = Cache::get('name');
By default, NULL will be returned if the cached item has expired or does not exist. However, you may pass a different default value as a second parameter to the method:
$name = Cache::get('name', 'Fred');
Now, "Fred" will be returned if the "name" cache item has expired or does not exist.
What if you need a value from your database if a cache item doesn't exist? The solution is simple. You can pass a closure into the **get** method as a default value. The closure will only be executed if the cached item doesn't exist:
Let's take this example a step further. Imagine you want to retrieve the number of registered users for your application; however, if the value is not cached, you want to store the default value in the cache. It's a breeze using the **remember** method:
Let's talk through that example. If the **count** item exists in the cache, it will be returned. If it doesn't exist, the result of the closure will be stored in the cache for five minutes **and** be returned by the method. Slick, huh?
Laravel even gives you a simple way to determine if a cached item exists using the **has** method:
if (Cache::has('name'))
{
$name = Cache::get('name');
}
<aname="forget"></a>
### Removing Items
Need to get rid of a cached item? No problem. Just mention the name of the item to the **forget** method:
Database configuration in Laravel is easy. The hardest part is deciding which database to use. Three popular open-source databases are supported out of the box:
- MySQL
- PostgreSQL
- SQLite
All of the database configuration options live in the **application/config/db.php** file. Let's get started.
<aname="quick"></a>
### Quick Start Using SQLite
[SQLite](http://sqlite.org) is an awesome, zero-configuration database system. By default, Laravel is configured to use a SQLite database. Really, you don't have to change anything. Just drop a SQLite database named **application.sqlite** into the **application/storage/db directory**. You're done.
Of course, if you want to name your database something besides "application", you can modify the database option in the SQLite section of the **application/config/db.php** file:
'sqlite' => array(
'driver' => 'sqlite',
'database' => 'your_database_name',
)
If your application receives less than 100,000 hits per day, SQLite should be suitable for production use in your application. Otherwise, consider using MySQL or PostgreSQL.
> **Note:** Need a good SQLite manager? Check out this [Firefox extension](https://addons.mozilla.org/en-US/firefox/addon/sqlite-manager/).
<aname="server"></a>
### Configuring MySQL or PostgreSQL
If you are using MySQL or PostgreSQL, you will need to edit the configuration options in **application/config/db.php**. Don't worry. In the configuration file, sample configurations exist for both systems. All you need to do is change the options as necessary for your server and set the default connection name.
'mysql' => array(
'driver' => 'mysql',
'host' => 'localhost',
'database' => 'database',
'username' => 'root',
'password' => 'password',
'charset' => 'utf8',
),
<aname="default"></a>
### Setting The Default Connection Name
As you have probably noticed, each database connection defined in the **application/config/db.php** file has a name. By default, there are three connections defined: **sqlite**, **mysql**, and **pgsql**. You are free to change these connection names. The default connection can be specified via the **default** option:
'default' => 'sqlite';
The default connection will always be used by the [fluent query builder](/docs/database/query) and [Eloquent ORM](/docs/database/eloquent). If you need to change the default connection during a request, use the **Config::set** method.
An ORM is an [object-relational mapper](http://en.wikipedia.org/wiki/Object-relational_mapping), and Laravel has one that you will absolutely love to use. It is named "Eloquent" because it allows you to work with your database objects and relationships using an eloquent and expressive syntax. In general, you will define one Eloquent model for each table in your database. To get started, let's define a simple model:
class User extends Eloquent {}
Nice! Notice that our model extends the **Eloquent** class. This class will provide all of the functionality you need to start working eloquently with your database.
> **Note:** Typically, Eloquent models live in the **application/models** directory.
<aname="conventions"></a>
### Conventions
Eloquent makes a few basic assumptions about your database structure:
- Each table should have a primary key named **id**.
- Each table name should be the plural form of its corresponding model name.
Sometimes you may wish to use a table name other than the plural form of your model. No problem. Just add a static **table** property your model:
class User extends Eloquent {
public static $table = 'my_users';
}
<aname="get"></a>
### Retrieving Models
Retrieving models using Eloquent is refreshingly simple. The most basic way to retrieve an Eloquent model is the static **find** method. This method will return a single model by primary key with properties corresponding to each column on the table:
$user = User::find(1);
echo $user->email;
The find method will execute a query that looks something like this:
SELECT * FROM "users" WHERE "id" = 1
Need to retrieve an entire table? Just use the static **all** method:
$users = User::all();
foreach ($users as $user)
{
echo $user->email;
}
Of course, retrieving an entire table isn't very helpful. Thankfully, **every method that is available through the fluent query builder is available in Eloquent**. Just begin querying your model with a static call to one of the [query builder](/docs/database/query) methods, and execute the query using the **get** or **first** method. The get method will return an array of models, while the first method will return a single model:
> **Note:** If no results are found, the **first** method will return NULL. The **all** and **get** methods return an empty array.
<aname="aggregates"></a>
### Aggregates
Need to get a **MIN**, **MAX**, **AVG**, **SUM**, or **COUNT** value? Just pass the column to the appropriate method:
$min = User::min('id');
$max = User::max('id');
$avg = User::avg('id');
$sum = User::sum('id');
$count = User::count();
Of course, you may wish to limit the query using a WHERE clause first:
$count = User::where('id', '>', 10)->count();
<aname="save"></a>
### Inserting & Updating Models
Inserting Eloquent models into your tables couldn't be easier. First, instantiate a new model. Second, set its properties. Third, call the **save** method:
$user = new User;
$user->email = 'example@gmail.com';
$user->password = 'secret';
$user->save();
Updating models is just as simple. Instead of instantiating a new model, retrieve one from your database. Then, set its properties and save:
$user = User::find(1);
$user->email = 'new_email@gmail.com';
$user->password = 'new_secret';
$user->save();
Need to maintain creation and update timestamps on your database records? With Eloquent, you don't have to worry about it. Just add a static **timestamps** property to your model:
class User extends Eloquent {
public static $timestamps = true;
}
Next, add **created_at** and **updated_at** date columns to your table. Now, whenever you save the model, the creation and update timestamps will be set automatically. You're welcome.
> **Note:** You can change the default timezone of your application in the **application/config/application.php** file.
<aname="relationships"></a>
### Relationships
Unless you're doing it wrong, your database tables are probably related to one another. For instance, an order may belong to a user. Or, a post may have many comments. Eloquent makes defining relationships and retrieving related models simple and intuitive. Laravel supports three types of relationships:
-[One-To-One](#one-to-one)
-[One-To-Many](#one-to-many)
-[Many-To-Many](#many-to-many)
To define a relationship on an Eloquent model, you simply create a method that returns the result of either the **has\_one**, **has\_many**, **belongs\_to**, or **has\_and\_belongs\_to\_many** method. Let's examine each one in detail.
<aname="one-to-one"></a>
#### One-To-One
A one-to-one relationship is the most basic form of relationship. For example, let's pretend a user has one phone. Simply describe this relationship to Eloquent:
class User extends Eloquent {
public function phone()
{
return $this->has_one('Phone');
}
}
Notice that the name of the related model is passed to the **has_one** method. You can now retrieve the phone of a user through the **phone** method:
$phone = User::find(1)->phone()->first();
Let's examine the SQL performed by this statement. Two queries will be performed: one to retrieve the user and one to retrieve the user's phone:
SELECT * FROM "users" WHERE "id" = 1
SELECT * FROM "phones" WHERE "user_id" = 1
Note that Eloquent assumes the foreign key of the relationship will be **user\_id**. Most foreign keys will follow this **model\_id** convention; however, if you want to use a different column name as the foreign key, just pass it in the second parameter to the method:
return $this->has_one('Phone', 'my_foreign_key');
Want to just retrieve the user's phone without calling the first method? No problem. Just use the **dynamic phone property**. Eloquent will automatically load the relationship for you, and is even smart enough to know whether to call the get (for one-to-many relationships) or first (for one-to-one relationships) method:
$phone = User::find(1)->phone;
What if you need to retrieve a phone's user? Since the foreign key (**user\_id**) is on the phones table, we should describe this relationship using the **belongs\_to** method. It makes sense, right? Phones belong to users. When using the **belongs\_to** method, the name of the relationship method should correspond to the foreign key (sans the **\_id**). Since the foreign key is **user\_id**, your relationship method should be named **user**:
class Phone extends Eloquent {
public function user()
{
return $this->belongs_to('User');
}
}
Great! You can now access a User model through a Phone model using either your relationship method or dynamic property:
echo Phone::find(1)->user()->first()->email;
echo Phone::find(1)->user->email;
<aname="one-to-many"></a>
#### One-To-Many
Assume a blog post has many comments. It's easy to define this relationship using the **has_many** method:
class Post extends Eloquent {
public function comments()
{
return $this->has_many('Comment');
}
}
Now, simply access the post comments through the relationship method or dynamic property:
$comments = Post::find(1)->comments()->get();
$comments = Post::find(1)->comments;
Both of these statements will execute the following SQL:
SELECT * FROM "posts" WHERE "id" = 1
SELECT * FROM "comments" WHERE "post_id" = 1
Want to join on a different foreign key? No problem. Just pass it in the second parameter to the method:
You may be wondering: _If the dynamic properties return the relationship and require less keystokes, why would I ever use the relationship methods?_ Actually, relationship methods are very powerful. They allow you to continue to chain query methods before retrieving the relationship. Check this out:
Many-to-many relationships are the most complicated of the three relationships. But don't worry, you can do this. For example, assume a User has many Roles, but a Role can also belong to many Users. Three database tables must be created to accomplish this relationship: a **users** table, a **roles** table, and a **roles_users** table. The structure for each table looks like this:
**Users:**
id - INTEGER
email - VARCHAR
**Roles:**
id - INTEGER
name - VARCHAR
**Roles_Users:**
user_id - INTEGER
role_id - INTEGER
Now you're ready to define the relationship on your models using the **has\_and\_belongs\_to\_many** method:
class User extends Eloquent {
public function roles()
{
return $this->has_and_belongs_to_many('Role');
}
}
Great! Now it's time to retrieve a user's roles:
$roles = User::find(1)->roles()->get();
Or, as usual, you may retrieve the relationship through the dynamic roles property:
$roles = User::find(1)->roles;
As you may have noticed, the default name of the intermediate table is the plural names of the two related models arranged alphabetically and concatenated by an underscore. However, you are free to specify your own table name. Simply pass the table name in the second parameter to the **has\_and\_belongs\_to\_many** method:
Eager loading exists to alleviate the N + 1 query problem. Exactly what is this problem? Well, pretend each Book belongs to an Author. We would describe this relationship like so:
class Book extends Eloquent {
public function author()
{
return $this->belongs_to('Author');
}
}
Now, examine the following code:
foreach (Book::all() as $book)
{
echo $book->author->name;
}
How many queries will be executed? Well, one query will be executed to retrieve all of the books from the table. However, another query will be required for each book to retrieve the author. To display the author name for 25 books would require **26 queries**. See how the queries can add up fast?
Thankfully, you can eager load the author models using the **with** method. Simply mention the **function name** of the relationship you wish to eager load:
foreach (Book::with('author')->get() as $book)
{
echo $book->author->name;
}
In this example, **only two queries will be executed**!
SELECT * FROM "books"
SELECT * FROM "authors" WHERE "id" IN (1, 2, 3, 4, 5, ...)
Obviously, wise use of eager loading can dramatically increase the performance of your application. In the example above, eager loading cut the execution time in half.
Need to eager load more than one relationship? It's easy:
Laravel provides an awesome, easy-to-use fluent interface for building SQL queries and working with your database. All queries use prepared statements and are protected against SQL injection. Working with your database doesn't have to be a headache.
You can begin a fluent query using the **table** method on the DB class. Just mention the table you wish to query:
$query = DB::table('users');
You now have a fluent query builder for the "users" table. Using this query builder, you can retrieve, insert, update, or delete records from the table.
<aname="get"></a>
### Retrieving Records
There are two methods available for retrieving records using a fluent query: **get** and **first**. The **get** method will return an array of records from your database. Each record will be an object with properties corresponding to the columns of the table:
$users = DB::table('users')->get();
foreach ($users as $user)
{
echo $user->email;
}
Instead of returning an array, the **first** method will return a single object:
$user = DB::table('users')->first();
echo $user->email;
It's easy to limit the columns returned by your query. Simply pass an array of columns you want into the **get** or **first** method:
$user = DB::table('users')->get(array('id', 'email as user_email'));
Need to get distinct records from the database? It's easy. Call the **distinct** method before retrieving your records:
$user = DB::table('users')->distinct()->get();
> **Note:** If no results are found, the **first** method will return NULL. The **get** method will return an empty array.
<aname="where"></a>
### Building Where Clauses
#### where and or\_where
Building WHERE clauses in Laravel is painless. There are a variety of methods to assist you. The most basic of these methods are the **where** and **or_where** methods. Here is how to use them:
return DB::table('users')
->where('id', '=', 1)
->or_where('email', '=', 'example@gmail.com')
->first();
Of course, you are not limited to simply checking equality. You may also use **greater-than**, **less-than**, **not-equal**, and **like**:
return DB::table('users')
->where('id', '>', 1)
->or_where('name', 'LIKE', '%Taylor%')
->first();
You may have assumed that the **where** method will add to the query using an AND condition, while the **or_where** method will use an OR condition. You assumed correctly.
#### where\_in, where\_not\_in, or\_where\_in, and or\_where\_not\_in
The suite of **where_in** methods allows you to easily construct queries that search an array of values:
Inserting records is amazingly easy using the **insert** method. The method only expects an array of values to insert. It couldn't be simpler. The insert method will simply return true or false, indicating whether the query was successful:
When making changes to your code, it's helpful to know the performance impact of your changes. Laravel provides a simple class to help you time code execution and check memory consumption. It's called the **Benchmark** class and it's a breeze to use.
<aname="timers"></a>
### Using Timers
To start a timer, simply call the **start** method on the Benchmark class and give your timer a name:
Benchmark::start('foo');
Pretty easy, right?
You can easily check how much time has elapsed (in milliseconds) using the **check** method. Again, just mention the name of the timer to the method:
echo Benchmark::check('foo');
<aname="memory"></a>
### Checking Memory Usage
Need to know how much memory is being used by your application? No problem. Just call the **memory** method to get your current memory usage in megabytes:
Need to do secure, two-way encryption? Laravel has you covered with the **Crypt** class. The Crypt class provides strong AES-256 encryption and decryption out of the box via the Mcrypt PHP extension.
To get started, you must set your **application key** in the **application/config/application.php** file. This key should be very random and very secret, as it will be used during the encryption and decryption process. It is best to use a random, 32 character alpha-numeric string:
'key' => 'xXSAVghP7myRo5xqJAnMvQwBc7j8qBZI';
Wonderful. You're ready to start encrypting.
> **Note:** Don't forget to install the Mcrypt PHP extension on your server.
<aname="encrypt"></a>
### Encrypting A String
Encrypting a string is a breeze. Just pass it to the **encrypt** method on the Crypt class:
Crypt::encrypt($value);
Do you feel like James Bond yet?
<aname="decrypt"></a>
### Decrypting A String
So you're ready to decrypt a string? It's simple. Just use the **decrypt** method on the Crypt class:
Crypt::decrypt($encrypted_value);
> **Note:** The decrypt method will only decrypt strings that were encrypted using **your** application key.
After a file has been uploaded to your application, you will want to move it from its temporary location to a permanent directory. You can do so using the **upload** method. Simply mention the **name** of the uploaded file and the path where you wish to store it:
File::upload('picture', 'path/to/pictures');
> **Note:** You can easily validate file uploads using the [Validator class](/docs/start/validation).
<aname="ext"></a>
### File Extensions
Need to get the extension of a file? Just pass the filename to the **extension** method:
File::extension('picture.png');
<aname="is"></a>
### Checking File Types
Often, it is important to know the type of a file. For instance, if a file is uploaded to your application, you may wish to verify that it is an image. It's easy using the **is** method on the **File** class. Simply pass the extension of the file type you are expecting. Here's how to verify that a file is a JPG image:
if (File::is('jpg', 'path/to/file.jpg'))
{
//
}
The **is** method does not simply check the file extension. The Fileinfo PHP extension will be used to read the content of the file and determine the actual MIME type. Pretty cool, huh?
> **Note:** You may pass any of the extensions defined in the **application/config/mimes.php** file to the **is** method.
<aname="mime"></a>
### Getting MIME Types
Need to know the MIME type associated with a file extension? Check out the **mime** method:
echo File::mime('gif');
The statement above returns the following string:
image/gif
> **Note:** This method simply returns the MIME type defined for the extension in the **application/config/mimes.php** file.
Localization is the process of translating your application into different languages. The **Lang** class provides a simple mechanism to help you organize and retrieve the text of your multilingual application.
All of the language files for your application live under the **application/lang** directory. Within the **application/lang** directory, you should create a directory for each language your application speaks. So, for example, if your application speaks English and Spanish, you might create **en** and **sp** directories under the **lang** directory.
Each language directory may contain many different language files. Each language file is simply an array of string values in that language. In fact, language files are structured identically to configuration files. For example, within the **application/lang/en** directory, you could create a **marketing.php** file that looks like this:
return array(
'welcome' => 'Welcome to our website!',
);
Next, you should create a corresponding **marketing.php** file within the **application/lang/sp** directory. The file would look something like this:
return array(
'welcome' => 'Bienvenido a nuestro sitio web!',
);
Nice! Now you know how to get started setting up your language files and directories. Let's keep localizing!
<aname="basics"></a>
### Retrieving A Language Line
To retrieve a language line, first create a Lang instance using the **line** method, then call the **get** method on the instance:
echo Lang::line('marketing.welcome')->get();
Notice how a dot was used to separate "marketing" and "welcome"? The text before the dot corresponds to the language file, while the text after the dot corresponds to a specific string within that file.
But, how did the method know which language directory to retrieve the message from? By default, the **get** method will use the language specified in your **application/config/application.php** configuration file. In this file you may set the default language of your application using the **language** option:
'language' => 'en'
Need to retrieve the line in a language other than your default? Not a problem. Just mention the language to the **get** method:
echo Lang::line('marketing.welcome')->get('sp');
<aname="replace"></a>
### Place Holders & Replacements
Now, let's work on our welcome message. "Welcome to our website!" is a pretty generic message. It would be helpful to be able to specify the name of the person we are welcoming. But, creating a language line for each user of our application would be time-consuming and ridiculous. Thankfully, you don't have to. You can specify "place-holders" within your language lines. Place-holders are preceeded by a colon:
'welcome' => 'Welcome to our website, :name!'
Then, simply pass an array of place-holder replacements to the **replace** method on a Lang instance:
The web is a stateless environment. This means that each request to your application is considered unrelated to any previous request. However, **sessions** allow you to store arbitrary data for each visitor to your application. The session data for each visitor is stored on your web server, while a cookie containing a **session ID** is stored on the visitor's machine. This cookie allows your application to "remember" the session for that user and retrieve their session data on subsequent requests to your application.
Sound complicated? If so, don't worry about it. Just tell Laravel where to store the sessions and it will take care of the rest.
Three great session drivers are available out of the box:
- File System
- Database
- Memcached
<aname="file"></a>
### File System Sessions
Most likely, your application will work great using file system sessions. However, if your application receives heavy traffic or runs on a server farm, use database or Memcached sessions.
To get started using file system sessions, just set the driver option in the **application/config/session.php** file:
'driver' => 'file'
That's it. You're ready to go!
> **Note:** File system sessions are stored in the **application/storage/sessions** directory, so make sure it's writeable.
<aname="database"></a>
### Database Sessions
To start using database sessions, you will first need to [configure your database connection](/docs/database/config).
Already setup your database? Nice! Next, you will need to create a session table. Here are some SQL statements to help you get started:
#### SQLite
CREATE TABLE "sessions" (
"id" VARCHAR PRIMARY KEY NOT NULL UNIQUE,
"last_activity" INTEGER NOT NULL,
"data" TEXT NOT NULL
);
#### MySQL
CREATE TABLE `sessions` (
`id` VARCHAR(40) NOT NULL,
`last_activity` INT(10) NOT NULL,
`data` TEXT NOT NULL,
PRIMARY KEY (`id`)
);
If you would like to use a different table name, simply change the **table** option in the **application/config/session.php** file:
'table' => 'sessions'
Great! All you need to do now is set the driver in the **application/config/session.php** file:
'driver' => 'db'
<aname="memcached"></a>
### Memcached Sessions
Before using Memcached sessions, you must [configure your Memcached servers](/docs/cache/config#memcached).
All done? Great! Just set the driver in the **application/config/session.php** file:
Storing items in the session is a breeze. Simply call the put method on the Session class:
Session::put('name', 'Taylor');
The first parameter is the **key** to the session item. You will use this key to retrieve the item from the session. The second parameter is the **value** of the item.
Need to store an item in the session that should expire after the next request? Check out the **flash** method. It provides an easy way to store temporary data like status or error messages:
Session::flash('status', 'Welcome Back!');
<aname="get"></a>
### Retrieving Items
Retrieving items from the session is no problem. You can use the **get** method on the Session class to retrieve any item in the session, including flash data. Just pass the key of the item you wish to retrieve:
$name = Session::get('name');
By default, NULL will be returned if the session item does not exist. However, you may pass a default value as a second parameter to the get method:
Now, "Fred" will be returned if the "name" item does not exist in the session.
Laravel even provides a simple way to determine if a session item exists using the **has** method:
if (Session::has('name'))
{
$name = Session::get('name');
}
<aname="forget"></a>
### Removing Items
Need to get rid of a session item? No problem. Just mention the name of the item to the **forget** method on the Session class:
Session::forget('name');
You can even remove all of the items from the session using the **flush** method:
Session::flush();
<aname="regeneration"></a>
### Regeneration
Sometimes you may want to "regenerate" the session ID. This simply means that a new, random session ID will be assigned to the session. Here's how to do it:
When starting a new project, you shouldn't be bombarded with loads of confusing configuration decisions. For that reason, Laravel is intelligently configured out of the box. The **application/config/application.php** file contains the basic configuration options for your application.
There is only one option that **must** be set when starting a new application. Laravel needs to know the URL you will use to access your application. Simply set the url in the **application/config/application.php** file:
'url' => 'http://localhost';
> **Note:** If you are using mod_rewrite, you should set the index option to an empty string.
<aname="clean"></a>
### Cleaner URLs
Most likely, you do not want your application URLs to contain "index.php". You can remove it using HTTP rewrite rules. If you are using Apache to serve your application, make sure to enable mod_rewrite and create a **.htaccess** file like this one in your **public** directory:
<IfModulemod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php/$1 [L]
</IfModule>
Is the .htaccess file above not working for you? Try this one:
Options +FollowSymLinks
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . index.php [L]
After setting up HTTP rewriting, you should set the **index** configuration option in **application/config/application.php** to an empty string.
> **Note:** Each web server has a different method of doing HTTP rewrites, and may require a slightly different .htaccess file.
<aname="errors"></a>
### Errors & Logging
-[404 Errors](#error-404)
-[Error Detail](#error-detail)
-[Logging](#error-logging)
<aname="error-404"></a>
#### 404 Errors
When a request is made to your application that cannot be matched to a route, the 404 error view will be sent to the browser. This view lives in **application/views/error/404.php** and you are free to modify it however you wish.
<aname="error-detail"></a>
#### Error Detail
You can easily control the level of error detail via the **detail** option in the **application/config/errors.php** file.
'detail' => true;
When set to **true**, error messages will be detailed with a stack trace and snippet of the relevant file. When set to **false**, the generic error page (**application/views/error/500.php**) will be displayed. Feel free to modify this view.
> **Note:** In a production environment, it is strongly suggested that you turn off error details.
<aname="error-logging"></a>
#### Logging
You may wish to log any errors that occur in your application. Laravel makes it a breeze. You can turn on logging by setting the log option to **true** in the **application/config/errors.php** file:
'log' => true;
You have total control over how your errors are logged via the **logger** function defined in **application/config/error.php**. This function is called every time there is an unhandled error or exception in your application.
As you can see, the default logger implementation writes to the **application/storage/log.txt** file; however, you are free to modify this function however you wish.
All web applications receive input via HTTP requests. The input can be sent to your application via any of the four HTTP verbs: **GET**, **POST**, **PUT**, or **DELETE**. Input can also be sent to your application via cookies, which can store small amounts of information and are stored on the user's computer.
Let's dig into the classes Laravel provides for working with user input!
> **Note:** Laravel doesn't mess with your query strings. Feel free to use them.
<aname="basics"></a>
## Input
The **Input** class handles input that comes into your application via GET, POST, PUT, or DELETE requests. Retrieving input using the Input class is effortless. Just use the **get** method:
$email = Input::get('email');
> **Note:** The get method is used for all request types, not just GET requests. You may use it on POST, PUT, and DELETE requests as well.
By default, NULL will be returned if the input item does not exist. However, you may pass a different default value as a second parameter to the method:
$name = Input::get('name', 'Fred');
Now, "Fred" will be returned if the "name" input item does not exist. You may even pass a closure as a default value:
Need to determine if an input item exists? Use the **has** method:
if (Input::has('name'))
{
$name = Input::get('name');
}
> **Note:** The **has** method will return **false** if the input item exists but is an empty string.
Need to access the **$_FILES** array? It's easy using the **file** method:
$picture = Input::file('picture');
$size = Input::file('picture.size');
Sometimes you may need to merge the input and $_FILES array. Check out the **all** method:
$input = Input::all();
<aname="old"></a>
## Old Input
Have you ever tried to re-populate an input form after an invalid form submission? It can get pretty clunky. Not in Laravel. You can easily retrieve the input from the previous request using the **old** method on the Input class:
$name = Input::old('name');
> **Note:** You must specifiy a session driver before using the **old** Input method.
As you would expect, you may pass a default value in the second parameter to the method:
$name = Input::old('name', 'Fred');
Once again, there is a simple way to determine if an old input item exists using the **had** method:
if (Input::had('name'))
{
$name = Input::old('name');
}
<aname="cookies"></a>
## Cookies
The **Cookie** class provides simple functions for retrieving, setting, and deleting cookies.
To retrieve a cookie value, simply mention its name to the **get** method:
$name = Cookie::get('name');
Of course, just like the Input class, you may pass a default value in the second parameter to the **get** method:
$name = Cookie::get('name', 'Fred');
Also just like the Input class, the Cookie class has a simple method to determine if a cookie exists:
if (Cookie::has('name'))
{
$name = Cookie::get('name');
}
Need to create a cookie? No problem. Check out the **put** method:
Cookie::put('name', 'Fred', 60);
The put method accepts almost the exact same parameters as the PHP setcookie method. However, just pass the number of **minutes** you want the cookie to live as the third parameter. You don't have to worry about any clunky expiration date calculations.
If you need to create a "permanent" cookie, try the **forever** method. It creates a cookie that lives for five years:
Cookie::forever('name', 'Fred');
To delete a cookie, use the **forget** method:
Cookie::forget('name');
<aname="forms"></a>
## Building Forms
-[Opening A Form](#form-open)
-[CSRF Protection](#form-csrf)
-[Labels](#form-labels)
-[Text, Text Area, Password & Hidden Fields](#form-text)
-[Checkboxes & Radio Buttons](#form-check)
-[Drop-Down Lists](#form-lists)
-[Buttons](#form-buttons)
Almost every web application receives input through HTML forms. As you have probably already learned, Laravel is here to make your life easier. That's why generating forms using the **Form** class is a breeze.
> **Note:** All input data displayed in elements generated by the **Form** class is filtered through the HTML::entities method.
<aname="form-open"></a>
### Opening A Form
Opening a form is simple. Just call the **open** method on the Form class:
echo Form::open();
When called without any parameters, the open method will create a form that will POST to the current URL. However, you'll probably want to point your forms to other URLs too. No problem. Just mention the URL to the method. You can even specify the request method (GET, POST, PUT, or DELETE) in the second parameter to the method:
echo Form::open('user/profile', 'PUT');
Need to apply a class or other attribute to the form tag generated by the open method? Simply pass an array of attributes as a third parameter:
> **Note:** The open method automatically prepares your form to receive UTF-8 input.
Need a form that can handle file uploads? Use the **open_for_files** method:
echo Form::open_for_files('user/profile');
<aname="form-csrf"></a>
### CSRF Protection
Laravel provides an easy method of protecting your application from [cross-site request forgeries](http://en.wikipedia.org/wiki/Cross-site_request_forgery). First, a random token is placed in your user's session. Don't sweat it, this is done automatically. Next, use the **token** method to generate a hidden form input field containing the random token on your form:
echo Form::token();
Now, simply [attach the built-in CSRF filter](/docs/start/routes#filters) to the route the form is posting to. If the token submitted by the form does not match the token in the user's session, the **application/views/error/500.php** view will be displayed.
Want to just get the CSRF token without generating a hidden input field? Use the **raw_token** method:
echo Form::raw_token();
> **Note:** Don't forget to [specify a session driver](/docs/session/config) before using these methods.
<aname="form-labels"></a>
### Labels
Need to generate a label for a form element? It's simple using the **label** method. Just pass the label name and display value to the method:
echo Form::label('email', 'E-Mail Address');
Of course, you may pass any attributes you wish in the third parameter to the method:
> **Note:** After creating a label, any form element you create with a name matching the label name will automatically receive an ID matching the label name as well.
<aname="form-text"></a>
### Text, Text Area, Password & Hidden Fields
Generating text boxes couldn't be easier. Just call the **text** method on the Form class and mention the name of the field:
echo Form::text('username');
Already have a value you want to put in the text box? Throw it in as a second parameter:
echo Form::text('email', 'example@gmail.com');
Again, any other attributes you wish to apply to the text box may be passed in an array as the third parameter:
> **Note:** The **password**, **hidden**, and **textarea** methods have the same signature as the text method. You just learned four methods for the price of one!
<aname="form-check"></a>
### Checkboxes & Radio Buttons
What website doesn't have a checkbox? Actually, this one doesn't! But, thankfully, generating them is simple using the **checkbox** method on the Form class. Just give the checkbox a name and a value:
echo Form::checkbox('remember', 'yes');
Of course, the example above will generate the following HTML:
<inputtype="checkbox"name="remember"value="yes">
Need to generate a "checked" checkbox? No problem. Simply pass **true** as the third parameter to the method:
echo Form::checkbox('remember', 'yes', true);
As always, you may specify any extra attributes that should be applied to the checkbox. Pass them as the fourth parameter to the method:
> **Note:** The **radio** method has the same signature as the checkbox method. Two for one!
<aname="form-lists"></a>
### Drop-Down Lists
Generating drop-down lists can be a headache. Thankfully, Laravel makes it refreshingly simple using the **select** method on the Form class. All you need to do is give your list a name and an array of options:
-[Wildcard URI Segments](/docs/start/routes#segments)
-[Named Routes](/docs/start/routes#named)
-[Route Filters](/docs/start/routes#filters)
-[Organizing Routes](/docs/start/routes#organize)
Unlike other PHP frameworks, Laravel places routes and their corresponding functions in one file: **application/routes.php**. This file contains the "definition", or public API, of your application. To add functionality to your application, you add to the array located in this file. It's a breeze.
<aname="define"></a>
## Defining Routes
All you need to do is tell Laravel the request methods and URIs it should respond to. You define the behavior of the route using an anonymous method:
'GET /home' => function()
{
// Handles GET requests to http://example.com/index.php/home
},
You can easily define a route to handle requests to more than one URI. Just use commas:
'POST /, POST /home' => function()
{
// Handles POST requests to http://example.com and http://example.com/home
}
> **Note:** The routes.php file replaces the "controllers" found in most frameworks. Have a fat model and keep this file light and clean. Thank us later.
<aname="segments"></a>
## Wildcard URI Segments
Laravel makes matching wildcard URI segments a breeze using the **(:num)** and **(:any)** place-holders. Check out these routes:
'PUT /user/(:num)' => function($id) {}
'DELETE /user/(:any)' => function($username) {}
Laravel will automatically pass the value of the wildcard segment into your route function.
> **Note:** The **(:any)** place-holder matches letters, number, dashes, and underscores.
Want to make an URI segment optional? No problem. Just put a **?** in the place-holder:
Notice the route now has an array value with two keys: **name** and **do**. As you learned while studying filters, the **do** value is the method that will be executed by the route. As you have probably guessed, the **name** value is the name of the route.
Now that you have named the route, you can [generate URLs](/docs/start/views#urls) and [perform redirects](/docs/start/views#redirect) using the route name instead of the route URI. This means that you can change the route URI as much as you want and the links to that route on your views will always be correct. It's beautiful, isn't it?
<aname="filters"></a>
## Route Filters
Filters are methods that run before and after a request to your application. "Before" filters can even halt the request cycle by returning a response, providing an amazingly simple way to implement common tasks like redirecting a user to a login view. Let's dig in.
All filters are defined in the **application/filters.php** file. Intuitive, right? If you open the file, you will see that four filters have already been defined for you: **before**, **after**, **auth**, and **csrf**. The **before** and **after** filters are the two "global" filters. They are always executed on every request, regardless of the request method or URI.
All other filters must be attached to individual routes. Don't worry, you'll learn how to do this soon. The built-in **auth** and **csrf** filters handle two scenarios that are common to almost every web application: redirecting users to a login page and protecting against cross-site request forgeries.
### Defining Filters
To define your own filter, simply add it to the array in the **application/filters.php** file:
'my_filter' => function()
{
return 'Filtered!';
}
### Attaching Filters To Routes
Alright, ready to attach the filter to a route? Do it like this:
Notice the route now has an array value with two keys: **before** and **do**. The **do** value is the method that will be executed by the route, while the **before** value contains the names of any filters that should be run before the method is executed.
Why stop with one filter? You can define multiple filters for a single route by separating the filter names with commas:
Remember, if a "before" filter returns a value, that value will be considered the output of the request. For example, the built-in **auth** filter checks if the user has logged in to your application. If they haven't, a [Redirect](/docs/start/views#redirect) to the login page is sent to the browser. Isn't the simplicity refreshing?
Of course, adding filters to run after the request is just as easy:
> **Note:** "After" filters receive the response returned by the route function that handled the request.
<aname="organize"></a>
## Organizing Routes
So, you're building the next monolithic web application and your **application/routes.php** file is getting a little cramped? Don't worry, we have you covered.
Here's what to do. First, create an **application/routes** directory. Great! You're almost there. Now, just add route files to **application/routes** corresponding to the base URIs of your application. So, a **photo.php** file within **application/routes** would handle all requests to URIs beginning with **/photo**. Similarly, a **user.php** file handles all requests to URIs beginning with **/user**. For example, check out this **user.php** file:
<?php
return array(
'GET /user/profile/(:num)' => function($id)
{
return View::make('user/profile');
}
);
The **application/routes.php** file will continue to be loaded on every request, so any "catch-all" routes can still be placed in that file. The **application/routes.php** file should also still contain the route for the root of your application.
Almost every interactive web application needs to validate data. For instance, a registration form probably requires the password to be confirmed. Maybe the e-mail address must be unique. Validating data can be a cumbersome process. Thankfully, it isn't in Laravel. The **Validator** class provides as awesome array of validation helpers to make validating your data a breeze.
To get started, let's imagine we have the following array:
If you don't like using arrays, you may also delimit rules using a pipe character:
$rules = array(
'name' => 'required|max:50',
'email' => 'required|email|unique:users',
);
Great! Now we're ready to make a **Validator** instance and validate our array:
$validator = Validator::make($array, $rules);
if ( ! $validator->valid())
{
return $validator->errors;
}
Via the **errors** property, you can access a simple error collector class that makes working with your error messages a breeze. Of course, default error messages have been setup for all validation rules. The default messages live in the **application/lang/en/validation.php** file.
Now you are familiar with the basic usage of the Validator class. You're ready to dig in and learn about the rules you can use to validate your data!
The **required** rule validates that an attribute is present in the array and is not an empty string:
$rules = array(
'name' => 'required',
);
<aname="rule-alphas"></a>
#### Alpha, Alpha Numeric, & Alpha Dash
The **alpha** rule validates that an attribute consists solely of letters:
$rules = array(
'name' => 'alpha',
);
The **alpha_num** rule validates that an attribute consists solely of letters and numbers:
$rules = array(
'username' => 'alpha_num',
);
The **alpha_dash** rule validates that an attribute consists solely of letters, numbers, dashes, and underscores:
$rules = array(
'username' => 'alpha_dash',
);
<aname="rule-size"></a>
#### Size
The **size** rule validates that an attribute is of a given length, or, if the attribute is numeric, is a given value:
$rules = array(
'name' => 'size:10',
);
The **between** rule validates that an attribute is between a given minimum and maximum:
$rules = array(
'payment' => 'between:10,50',
);
> **Note:** All minimum and maximum checks are inclusive.
The **min** rule validates that an attribute is greater than or equal to a given value:
$rules = array(
'payment' => 'min:10',
);
The **max** rule validates that an attribute is less than or equal to a given value:
$rules = array(
'payment' => 'max:50',
);
<aname="rule-numeric"></a>
#### Numericality
The **numeric** rule validates that an attribute is (surprise!) numeric:
$rules = array(
'payment' => 'numeric',
);
The **integer** rule validates that an attribute is an integer:
$rules = array(
'payment' => 'integer',
);
<aname="rule-inclusion"></a>
#### Inclusion & Exclusion
The **in** rule validates that an attribute is contained in a list of values:
$rules = array(
'size' => 'in:small,medium,large',
);
The **not_in** rule validates that an attribute is not contained in a list of values:
$rules = array(
'language' => 'not_in:cobol,assembler',
);
<aname="rule-confirmed"></a>
#### Confirmation
The **confirmed** rule validates that, for a given attribute, a matching **attribute_confirmation** attribute exists. For example, given the following rule:
$rules = array(
'password' => 'confirmed',
);
The Validator will make sure that the **password** attribute matches the **password_confirmation** attribute in the array being validated.
<aname="rule-accepted"></a>
#### Acceptance
The **accepted** rule validates that an attribute is equal to **yes** or **1**. This rule is helpful for validating checkbox form fields such as "terms of service".
$rules = array(
'terms' => 'accepted',
);
<aname="rule-unique"></a>
#### Uniqueness
The **unique** rule validates the uniqueness of an attribute on a given database table:
$rules = array(
'email' => 'unique:users',
);
In the example above, the **email** attribute will be checked for uniqueness on the **users** table. Need to verify uniqueness on a column name other than the attribute name? No problem:
$rules = array(
'email' => 'unique:users,email_address',
);
<aname="rule-email"></a>
#### E-Mail Addresses
The **email** rule validates that an attribute contains a correctly formatted e-mail address:
$rules = array(
'email' => 'email',
);
<aname="rule-urls"></a>
#### URLs
The **url** rule validates that an attribute contains a correctly formatted URL:
$rules = array(
'link' => 'url',
);
The **active_url** rule uses the PHP **checkdnsrr** function to verify that a URL is active:
$rules = array(
'link' => 'active_url',
);
<aname="rule-uploads"></a>
#### Uploads
The **mimes** rule validates that an uploaded file has a given MIME type. This rule uses the PHP Fileinfo extension to read the contents of the file and determine the actual MIME type. Any extension defined in the **application/config/mimes.php** file may be passed to this rule as a parameter:
The **image** rule validates that an uploaded file has a **jpg**, **gif**, **bmp**, or **png** MIME type:
$rules = array(
'picture' => 'image',
);
You may also validate the size of an upload using the **max** rule. Simply specify the maximum number of **kilobytes** the upload may be:
$rules = array(
'picture' => 'image|max:100',
);
<aname="errors"></a>
### Retrieving Error Messages
Laravel makes working with your error messages a cinch using a simple error collector class. After calling the **valid** or **invalid** method on a **Validator** instance, you may access the errors via the **errors** property:
if ( ! $validator->valid())
{
return $validator->errors;
}
The error collector has the following simple functions for retrieving your error messages: **has**, **first**, **get**, and **all**.
The **has** method will check if an error message exists for a given attribute:
if ($validator->errors->has('email'))
{
// The e-mail attribute has errors...
}
The **first** method will return the first error message for a given attribute:
echo $validator->errors->first('email');
Sometimes you may need to format the error message by wrapping it in HTML. No problem. Along with the **:message** place-holder, pass the format as the second parameter to the method:
Want to use an error message other than the default? Maybe you even want to use a custom error message for a given attribute and rule. Either way, the **Validator** class makes it easy.
Simply create an array of custom messages to pass to the Validator instance:
$messages = array(
'required' => 'The :attribute field is required.',
Great! Now our custom message will be used anytime a **required** validation check fails. But, what is this **:attribute** stuff in our message? To make your life easier, the Validator class will replace the **:attribute** place-holder with the actual name of the attribute! It will even remove underscores from the attribute name.
You may also use the **:size**, **:min**, **:max**, and **:values** place-holders when constructing your error messages:
$messages = array(
'size' => 'The :attribute must be exactly :size.',
'between' => 'The :attribute must be between :min - :max.',
'in' => 'The :attribute must be one of the following types: :values',
);
So, what if you need to specify a custom **required** message, but only for the **email** attribute? No problem. Just specify the message using an **attribute_rule** naming convention:
$messages = array(
'email_required' => 'We need to know your e-mail address!',
);
In the example above, the custom required message will be used for the **email** attribute, while the default message will be used for all other attributes.
<aname="custom"></a>
### Creating Custom Validation Rules
Need to create your own validation rules? You will love how easy it is! First, create a class that extends **System\Validator** and place it in your **application/libraries** directory:
<?php
class Validator extends System\Validator {}
Next, remove the **Validator** alias from **application/config/aliases.php**.
Alright! You're ready to define your own validation rule. Create a function on your new validator using a **validate_rule** naming convention. Validator methods simply need to return **true** or **false**. It couldn't be any easier, right?
<?php
class Validator extends System\Validator {
public function validate_awesome($attribute, $parameters)
{
return $attribute == 'awesome';
}
}
Let's dig into this example. The **validate_awesome** function receives two arguments. The first is the value of the attribute being validated, the second is an array of parameters that were specified for the rule, such as a size or list of accepted values (more on that in a second).
Now, how do you use your new validator? It's refreshingly simple:
$rules = array(
'username' => 'required|awesome',
);
Of course, you will need to define an error message for your new rule. You can do this either in an ad-hoc messages array:
$messages = array(
'awesome' => 'The attribute value must be awesome!',
-[Nesting Views Within Views](/docs/start/views#nest)
-[Redirects](/docs/start/views#redirect)
-[Downloads](/docs/start/views#downloads)
-[Building URLs](/docs/start/views#urls)
-[Building HTML](/docs/start/views#html)
<aname="create"></a>
## Creating Views
Typically, a route function returns a **View**. Views consist of plain ole' HTML and are stored in your **application/views** directory.
A very simple view file could look like this:
<html>
Welcome to my website!
</html>
Assuming this view lives in **application/views/simple.php**, we could return it from a route like so:
'GET /home' => function()
{
return View::make('simple');
}
When building a large application, you may want to organize your views into sub-directories. That's a great idea! Assuming a view lives in **application/views/user/login.php**, we could return it like so:
'GET /home' => function()
{
return View::make('user/login');
}
It's that simple. Of course, you are not required to return a View. Strings are also welcome:
'GET /home' => function()
{
return json_encode('This is my response!');
}
<aname="bind"></a>
## Binding Data To Views
You can pass data to a view by "binding" the data to a variable. This is done using the **bind** method on the View:
In the example above, the first parameter is the **name** of the view variable. The second parameter is the **value** that will be assigned to the variable.
Now, in our view, we can access the e-mail address like so:
<html>
<?php echo $email; ?>
</html>
Of course, we can bind as many variables as we wish:
'GET /home' => function()
{
return View::make('simple')
->bind('name', 'Taylor')
->bind('email', 'example@gmail.com');
}
You may also bind view data by simply setting properties on a view instance:
'GET /home' => function()
{
$view = View::make('user/login');
$view->name = 'Taylor';
$view->email = 'example@gmail.com';
return $view;
}
<aname="nest"></a>
## Nesting Views Within Views
Want to nest views inside of views? There are two ways to do it, and they are both easy. First, you can bind the view to a variable:
'GET /home' => function()
{
$view = View::make('user/login');
$view->content = View::make('partials/content');
$view->footer = View::make('partials/footer');
return $view;
}
Or, you can get the string content of a view using the **get** method:
<html>
<?phpechoView::make('content')->get(); ?>
<?phpechoView::make('footer')->get(); ?>
</html>
<aname="redirect"></a>
## Redirects
### Redirect Using URIs
You will often need to redirect the browser to another location within your application. The **Redirect** class makes this a piece of cake. Here's how to do it:
'GET /redirect' => function()
{
return Redirect::to('user/profile');
}
Of course, you can also redirect to the root of your application:
return Redirect::to('/');
Need to redirect to a URI that should be accessed over HTTPS? Check out the **to_secure** method:
return Redirect::to_secure('user/profile');
You can even redirect the browser to a location outside of your application:
return Redirect::to('http://www.google.com/');
<aname="named"></a>
### Redirect Using Named Routes
So far we've created redirects by specifying a URI to redirect to. But, what if the URI to the user's profile changes? It would be better to create a redirect based on the [route name](/docs/start/routes#named). Let's learn how to do it. Assuming the user profile route is named **profile**, you can redirect to the route using a dynamic, static method call like this:
return Redirect::to_profile();
Need to redirect to a route that should be accessed over HTTPS? No problem:
return Redirect::to_secure_profile();
That's great! But, what if the route URI looks like this:
You need to redirect to the named route, but you also need to replace the **(:any)** place-holders in the URI with actual values. It sounds complicated, but Laravel makes it a breeze. Just pass the parameters to the method in an array:
After a user creates an account or signs into your application, it is common to display a welcome or status message. But, how can you set the status message so it is available for the next request? The **Response** and **Redirect** classes make it simple using the **with** method. This method will add a value to the Session flash data, which will be available for the next request:
> **Note:** For more information regarding Sessions and flash data, check out the [Session documentation](/docs/session/config).
<aname="downloads"></a>
## Downloads
Perhaps you just want to force the web browser to download a file? Check out the **download** method on the **File** class:
'GET /file' => function()
{
return File::download('path/to/your/file.jpg');
}
In the example above, the image will be downloaded as "file.jpg", however, you can easily specify a different filename for the download in the second parameter to the method:
-[Generating URLs Using Named Routes](#named-urls)
-[URL Slugs](#url-slugs)
While developing your application, you will probably need to generate a large number of URLs. Hard-coding your URLs can cause headaches if you switch domains or application locations. Nobody wants to dig through every view in their application to change URLs. Thankfully, the **URL** class provides some simple methods that allow you to easily generate URLs for your application.
<aname="uri-urls"></a>
### Generating URLs Using URIs
To generate a URL for your application, use the **to** method on the URL class:
echo URL::to();
The statement above will simply return the URL specified in your **application/config/application.php** file.
However, this method can also append a specified string to the end of your application URL:
echo URL::to('user/profile');
Now the statement will generate a URL something like this:
http://example.com/index.php/user/login
Need to generate a HTTPS URL? No problem. Check out the **to\_secure** method:
echo URL::to_secure('user/profile');
Often, you will need to generate URLs to assets such as images, scripts, or styles. You don't want "index.php" inserted into these URLs. So, use the **to_asset** method:
echo URL::to_asset('img/picture.jpg');
<aname="named-urls"></a>
### Generating URLs To Named Routes
Alright, you have learned how to generate URLs from URIs, but what about from named routes? You can do it by making a dynamic, static method call to the URL class. The syntax is beautiful:
echo URL::to_profile();
Have a route that needs to be accessed over HTTPS? No problem:
echo URL::to_secure_profile();
Could it get any easier? Now, imagine a route that is defined like this:
To generate a URL for the route, you need to replace the **(:any)** place-holders with actual values. It's easy. Just pass the parameters to the method in an array:
When writing an application like a blog, it is often necessary to generate URL "slugs". Slugs are URL friendly strings of text that represent something like a blog post title. Generating slugs is a piece of cake using the **slug** method:
echo URL::slug('My blog post title!');
The statement above will return the following string:
my-blog-post-title
Want to use a different separator character? Just mention it to the method:
echo URL::slug('My blog post title!', '_');
<aname="html"></a>
## Building HTML
-[Entities](#html-entities)
-[JavaScript & Style Sheets](#html-styles)
-[Links](#html-links)
-[Links To Named Routes](#html-route-links)
-[Mail-To Links](#html-mailto)
-[Images](#html-images)
-[Lists](#html-lists)
Need some convenient methods that make writing HTML a little less painful? Introducing the **HTML** class. Enjoy.
<aname="html-entities"></a>
### Entities
When displaying user input in your Views, it is important to convert all characters which have signifance in HTML to their "entity" representation.
For example, the < symbol should be converted to its entity representation. Converting HTML characters to their entity representation helps protect your application from cross-site scripting. Thankfully, using the **entities** method on the HTML class, it's easy to add this layer of protection to your Views:
To generate a link to the route, you need to replace the **(:any)** place-holder with an actual value. It's easy. Just pass the parameters to the method in an array:
echo HTML::link_to_login(array('user'));
This statement will generate a link to the following URL:
http://example.com/login/user
<aname="html-mailto"></a>
### Mail-To Links
It's great to allow your users to get in touch with you, but you don't want to be bombarded by spam. Laravel doesn't want you to be either. The **mailto** method allows you to create a safe mail-to link that obfuscates your e-mail address:
echo HTML::mailto('example@gmail.com');
Want the link text to be something besides your e-mail address? No problem. Just mention it to the method:
Need to obfuscate an e-mail address but don't want to generate an entire mail-to link? Simply pass the e-mail address to the **email** method:
echo HTML::email('example@gmail.com');
<aname="html-images"></a>
### Images
Since you're building a creative application, you will need to include some images. The **image** method makes simple. Just pass the URL and Alt text to the method:
echo HTML::image('img/smile.jpg', 'A Smiling Face');
Like the link method, any other attributes that should be applied to the image may be passed in the third parameter to the method:
echo HTML::image('img/smile.jpg', 'A Smiling Face', array('id' => 'smile'));
<aname="html-lists"></a>
### Lists
Generating HTML lists doesn't have to be a headache. Check out the **ol** method. All it needs is an array of items:
