Laravel.IO @laravelio - Tumblr Blog

Contributing to the Laravel Project

I apologize but I'm sick so today's topic is going to be short. By contributing to Laravel you can help fix bugs and improve the framework for all. Laravel has some contribution guidelines that can be found in [CONTRIBUTING.md](https://github.com/laravel/laravel/blob/master/CONTRIBUTING.md). Give these a read and if you ever spot a bug or something that you'd like to see improved (especially documentation) then consider contributing. # Pull request guidelines [GitHub pull requests](https://help.github.com/articles/using-pull-requests) are a great way for everyone in the community to contribute to the Laravel codebase. Found a bug? Just fix it in your fork and submit a pull request. This will then be reviewed, and, if found as good, merged into the main repository. In order to keep the codebase clean, stable and at high quality, even with so many people contributing, some guidelines are necessary for high-quality pull requests: - **Branch:** Unless they are immediate documentation fixes relevant for old versions, pull requests should be sent to the `develop` branch only. Make sure to select that branch as target when creating the pull request (GitHub will not automatically select it.) - **Documentation:** If you are adding a new feature or changing the API in any relevant way, this should be documented. The documentation files can be found directly in the core repository. - **Unit tests:** To keep old bugs from re-appearing and generally hold quality at a high level, the Laravel core is thoroughly unit-tested. Thus, when you create a pull request, it is expected that you unit test any new code you add. For any bug you fix, you should also add regression tests to make sure the bug will never appear again. If you are unsure about how to write tests, the core team or other contributors will gladly help.

#Laravel 3.2 #contributing

The Lifecycle of a Laravel Request Part 2

Today we're going to finish learning the basics of the Laravel request lifecycle. Last time we read the public/index.php file and the laravel/core.php file. Today we'll continue by finishing laravel/laravel.php. After laravel/core.php is loaded laravel/laravel.php will handle the following tasks: 1. setup error and exception handlers 2. temporarily enable all php errors 3. start the default bundle (your application folder) 4. register a catch-all route. if your application or bundle's routes don't respond to a request, the catch-all will and it returns a 404 5. grab the language information from config and set the current language based on the uri 6. finally Laravel requests the route information from the router and calls the routed code, capturing the response into a variable 7. the response is then rendered to a string from the response object 8. the session is then saved using the chosen session driver 9. finally, the laravel.done event is fired and passed the response object **Our Goal for the Day** It's all pretty straight-forward here. But, we need to read the code and understand what it's doing so that we can leverage this knowledge going forward. Today's topic completes our reading of public/index.php, laravel/laravel.php, and laravel/core.php. Post any questions in the comments below. **Required Reading** [laravel/laravel.php](https://github.com/laravel/laravel/blob/master/laravel/laravel.php)

#Laravel 3.2 #lifecylce #request

The Laravel View Class

Today's topic is the Laravel View class. Here's a class that we're using very regularly. Actually, the only time that we're not using it is when we're writing an API. Still, how much functionality is packed inside the class that we never knew about? Today's topic is short because there's not so much to talk about as much as there is something to do. It's time to reach out and take control of one of the most commonly used classes in the framework. When reading through the class pay special attention to the data that the constructor takes and what it does with it, how the view generates the $errors variable, and the many useful functions such as exists(), file(), of(), name(), render(), etc. Let's make today the last day that we don't have mastery over our View class. **Required Reading** [The Laravel View class](https://github.com/laravel/laravel/blob/master/laravel/view.php) **Extracurricular Activities** To better beat the information into our heads we can work up a test and use the various methods that we never knew about.

#Laravel 3.2 #views

The Lifecycle of a Laravel Request Part 1

Today we're going to BEGIN looking into the lifecycle of a Laravel request. Laravel 3 is bootstrapped primarily by 3 files. public/index.php, laravel/laravel.php and laravel/core.php. When a request first hits your server it is likely to hit a .htaccess file (in most cases) and the request will be received by public/index.php. Let's start by looking at public/index.php: /** * Laravel - A PHP Framework For Web Artisans * * @package Laravel * @version 3.2.12 * @author Taylor Otwell * @link http://laravel.com */ // -------------------------------------------------------------- // Tick... Tock... Tick... Tock... // -------------------------------------------------------------- define('LARAVEL_START', microtime(true)); // -------------------------------------------------------------- // Indicate that the request is from the web. // -------------------------------------------------------------- $web = true; // -------------------------------------------------------------- // Set the core Laravel path constants. // -------------------------------------------------------------- require '../paths.php'; // -------------------------------------------------------------- // Unset the temporary web variable. // -------------------------------------------------------------- unset($web); // -------------------------------------------------------------- // Launch Laravel. // -------------------------------------------------------------- require path('sys').'laravel.php'; As you can see here the request begins with setting a timestamp. This will be used for profiling the request. Next, we register the paths for our application. We're familiar with the paths.php file from a previous study on registering and generating paths. Finally, index.php includes laravel/laravel.php. As you can imagine from the name, laravel.php is a critical part of our request's lifecycle. However, as going over the entire cycle in one post is not possible, we'll start by focusing on laravel.php's first action.. including laravel/core.php. In the next installment of this series we'll continue with the rest laravel/laravel.php. **laravel/core.php** handles the following things in the following order: 1. **registers various constants** that Laravel will be using for handling the rest of the request, (EXT, CRLF, BLADE_EXT, DEFAULT_BUNDLE, MB_STRING) 2. **begins output buffering**, this prevents output from causing redirection failures, etc 3. **loads some core classes**, ioc, event, bundle, config, the autoloader and the helper functions 4. **registers the framework autoloader** with spl_autoload_register() 5. **registers the Laravel namespace** with the autoloader so that classes loaded with \Laravel\ will be autoloaded from the laravel/ folder 6. **registers Eloquent relationship classes** with the autoloader since they use non-standard naming conventions 7. **registers Symfony components** that Laravel uses with the autoloader 8. if magic_quotes are enabled, **strip slashes from input arrays** $_GET, $_POST, $_COOKIE and $_REQUEST 9. at this point Laravel **instantiates the HTTPFoundation abstraction layer** 10. then, we **determine and set the application environment** variable either from the artisan command-line option or from detecting the environment from the URL 11. **register any artisan CLI arguments in the $_SERVER array** should the artisan command line utility be used to create this request 12. finally, **core.php registers all of the bundles from bundles.php**. these won't be started yet. With these tasks completed, we're ready to procede with the rest of laravel/laravel.php. We'll be going over it in the next installment of this series (day after tommorrow). **Our Goal for the Day** We want to get a good idea about how Laravel starts up and gets going. This will enable us to more easily troubleshoot problems and empower us to better understand what a framework must do to get started. We're generally intimately familiar with the middle and end of a framework's processing, but we often overlook the beginning. **Required Reading** [public/index.php](https://github.com/laravel/laravel/blob/master/public/index.php) Where the request lands. [laravel/laravel.php](https://github.com/laravel/laravel/blob/master/laravel/laravel.php) We just need to read up to the first action (which is including core.php). [laravel/core.php](https://github.com/laravel/laravel/blob/master/laravel/core.php) Read this file thoroughly and understand everything about it. If you have questions feel free to post them below in the comments. **Extracurricular Activity** As if today's topic isn't expansive enough?

#laravel 3.2 #request #lifecycle #bootstrap

Naming Attributes for Validation Messages

Today's topic is over setting attribute display names for validation messages. Let's say that we have the following form: {{ Form::open() }} Email: {{ Form::text('email', Input::old('email')) }} {{ $errors->first('email', ':message') }} Password: {{ Form::password('password') }} {{ $errors->first('password', ':message') }} {{ Form::submit('Login') }} {{ Form::close() }} And our validation looks something like this: $rules = array( 'email' => 'required', ); $validation = new Validator(Input::all(), $rules); if(!$validation->passes()) { return Redirect::back()->with_input()->with_errors($validation); } If we post our form without an email address we'll get the error, "The email field is required." That's not so bad. But, what if we wanted to change the message to something like.. "The E-mail address field is required."? Well, we COULD make a custom validation message. But, that may be a bit of overkill for what we're wanting to do as we'll have to make custom validation messages for every rule assigned to the 'email' field. Instead we can load up our trusty language file and change how the email field is returned in validator error messages. By default we use English and therefore we will load up [application/language/en/validation.php](https://github.com/laravel/laravel/blob/master/application/language/en/validation.php#L87). At the bottom we see the attributes array. /* |-------------------------------------------------------------------------- | Validation Attributes |-------------------------------------------------------------------------- | | The following language lines are used to swap attribute place-holders | with something more reader friendly such as "E-Mail Address" instead | of "email". Your users will thank you. | | The Validator class will automatically search this array of lines it | is attempting to replace the :attribute place-holder in messages. | It's pretty slick. We think you'll like it. | */ 'attributes' => array(), This array can be used as a hash for field names and their equivalent display name. Let's change the array to... 'attributes' => array( 'email' => 'E-mail Address', ), ... and run the validation again. Now, we get back the error, "The E-mail Address field is required." In this way we can set our attributes' display names for various languages and prevent the need to create a plethora of custom validator messages. **Our Goal for the Day** It's Monday, relax and transition back into work. **Required Reading** Just what you've already read of this post. **Extracurricular Activity** Read over the [message() method in laravel/validator.php](https://github.com/laravel/laravel/blob/master/laravel/validator.php#L761) to see how the validator constructs messages.

#attributes #language #validation #Laravel 3.2

Getting Information about a Route

Today's topic is over accessing information about the current route. Gaining this information is easy enough, take a look at this example: Route::get('test', function() { dd(Request::route()); }); As you no doubt remember from our 'helpers' topic dd() is a shortcut for die(var_dump($variable)); and it's super useful. When we run this we get the following result: object(Laravel\Routing\Route)#30 (7) { ["uri"]=> string(4) "test" ["method"]=> string(3) "GET" ["bundle"]=> string(11) "application" ["controller"]=> NULL ["controller_action"]=> NULL ["action"]=> array(2) { [0]=> object(Closure)#19 (0) { } ["https"]=> bool(false) } ["parameters"]=> array(0) { } } This isn't terribly useful, but let's take a look at what we get when we run it within a controller: object(Laravel\Routing\Route)#30 (7) { ["uri"]=> string(13) "login/(:all?)" ["method"]=> string(3) "GET" ["bundle"]=> string(11) "application" ["controller"]=> string(4) "auth" ["controller_action"]=> string(5) "login" ["action"]=> array(2) { ["uses"]=> string(10) "auth@login" ["https"]=> bool(false) } ["parameters"]=> array(0) { } } This is much more useful! As you can see I accessed this request with http://whatever.com/login and it's calling the 'login' action in the 'auth' controller. Let's check out an example with parameters. object(Laravel\Routing\Route)#30 (7) { ["uri"]=> string(14) "search/(:all?)" ["method"]=> string(3) "GET" ["bundle"]=> string(11) "application" ["controller"]=> string(6) "search" ["controller_action"]=> string(5) "index" ["action"]=> array(3) { ["uses"]=> string(12) "search@index" ["before"]=> string(4) "auth" ["https"]=> bool(false) } ["parameters"]=> array(1) { [0]=> string(5) "shawn" } } In this example I accessed http://whatever.com/search/shawn. This is all super handy information... But, check this out... you can use the 'uses' and 'parameters' to generate URLs. $uses = Request::route()->action['uses']; $parameters = Request::route()->parameters; return Redirect::to_action($uses, $parameters); In this way we can know what action we're trying to run as well as our parameters, then we can generate new URLs based on this information. One way in which I use this is to store the action and parameters in session when an auth filter forces a user to the login page. Upon successful logic I'll check to see if these variables are in session and generate a Redirect::to_action() to take them post-login to where they intended to go. **Our Goal for the Day** Today is an easy one. Check out the kind of info available in Request::route() for various locations in one of your applications and get a good grasp on what you can use it for. **Required Reading** [laravel/laravel.php](https://github.com/laravel/laravel/blob/master/laravel/laravel.php#L152), where the route is assigned [routing/router.php](https://github.com/laravel/laravel/blob/master/laravel/routing/router.php#L449), where routing information is distilled from a method and URI **Extracurricular Activities** Get down and dirty with routing/router.php's route() function. Seriously, check it out. You'll be impressed. For example: dd(Router::route('GET', 'login')); I know, right?

#routing #Laravel 3.2

Laravel's Messages Class - It's Not Just for Validation Errors!

The Messages class is used for storing, returning, and formatting messages. You may be already somewhat familiar with the functionality of this class because it's used for accessing validation errors in the view. But, it's a simple and powerful class with a wide variety of potential use-cases. At the core of the Messages class is its $messages array. $messages is a multi-dimensional array that stores a list of messages under a key. For example, the 'password' key might contain an array with the messages 'your passwords do not match' and 'your password must be at least 5 characters'. It looks something like this (in pseudo whatever): $messages['password'] = array( 'your passwords do not match', 'your password must be at least 5 characters', ); **Adding Messages** The Messages class' add() method allows you to add values to the $messages array. **Checking for Messages** Like other Laravel classes, you can test whether or not the Messages class contains messages for a certain key with the has() method. **Returning Messages** There are a few options for returning messages. The first() method returns the first message available for a key. If the key password has the 2 messages that we listed above then $messages->first('password') method would return "your passwords do not match". The get() method retuns all of the messages available for a key as an array. The all() method returns all of the messages for each and every key. **Formatting Messages** You'll notice that the retrieval methods all accept 'format' parameters. This is a wonderful feature that you'll be using a lot. By passing a format string you can easily format messages into the form that you need, cleaning up your code quite a bit. Imagine that we're in a form and we want to show the most relevant error for the password field. (Since the $errors object available within views is an instance of the message class, you can do this right out of the gate already!) {{ Form::password('password') }} {{ $errors->first('password', ':message') }} In the case of our example this will output: your passwords do not match How useful is that! **Our Goal for the Day** Today we want to really master the Messages class. It's a short and simple class with a wide array of potential use cases. Many of us are probably using our own home-grown solutions where we could be simplifying our lives by using Laravel's Messages class. In addition, we want to truly understand how the validator uses the Messages class for errors and how Laravel's view class creates an instance of the Messages class to make errors available in the view. In this way we can better handle passing errors, etc to our views using this built-in functionality. Create something like: Route::get('test', function() { $messages = new \Laravel\Messages; // do cool stuff here }); Use and really get to know the functionality of the Messages class. **Required Reading** [Laravel's Messages class](https://github.com/laravel/laravel/blob/master/laravel/messages.php) [Laravel's Validator class](https://github.com/laravel/laravel/blob/master/laravel/validator.php#L220) (focus on use of the Messages class) [Laravel's View class](https://github.com/laravel/laravel/blob/master/laravel/view.php#L103) (focus on use of the Messages class) **Extracurricular Activity** Everything is super important today. So, it's all 'required'.

#errors #formatting #messages #validation #Laravel 3.2

Registering and Generating Paths

Today's topic is Laravel's method of path generation. Quick Note: As an attempt to pace the study group a bit, I'm going to try to use Tuesdays and Thursdays for more advanced topics and Mondays, Wednesdays, and Fridays for simpler topics. The paths.php file that exists at the root of the Laravel installation defines environments, the directory separator, default paths, and the path functions. We'll go into environments in another topic. For now, it's Wednesday and we're focused on paths. The paths that are set by default are app, sys, bundle, storage, and public. These correspond to the application, laravel, bundles, storage, and public folders in your Laravel installation. Path definitions are relative to the Laravel base installation directory (the directory that paths.php sits within). The path functions defined in this file are path() and set_path(). They're pretty self-explanatory. path() allows you to retrieve a path, set_path() enables you to add one to the laravel paths global variable. Note that set_path() doesn't store anything long-term. A path added with set_path() will not exist in subsequent requests. As you need more paths defined in your application you would add them here and utilize the path() function to access them across your app. We want to think of paths.php as the definitive location to store our application's paths. **Our Goal for the Day** Read paths.php and pay attention to what path options are available. Consider how how we can register our own paths in paths.php and utilize path() throughout our site as a standard method of generating paths. **Required Reading** [paths.php](https://github.com/laravel/laravel/blob/master/paths.php), of course

#paths #Laravel 3.2

Laravel's Fluent Class - No, not the query-builder.

Today's topic is Laravel's Fluent class. We're not talking about the Fluent query-builder. Fluent is defined as: _Able to express oneself easily and articulately: "a fluent speaker and writer on technical subjects"._ It should be of no surprise that the Fluent class is designed to make it easier to access data from an object or an array. Step 1) Use the Fluent class to 'wrap' an object or array. $my_thoughts = array('cats' => 'sneezing', 'dogs' => 'pooing'); $pets = new \Laravel\Fluent($my_thoughts); Now we can access the data using the new Fluent object. echo $pets->cats; echo $pets->dogs; One benefit is that should you try: echo $my_thoughts['snakes']; You'll get an 'undefined index' error. With the Fluent class you will simply get null. You also have the power of the array_get() helper that we learned yesterday! As you know the array_get() helper allows you to use array dot notation to easily and cleanly retrieve data from arrays. For example, you can do the following: $data = array('people' => array('chrono' => 'ordinary', 'marle' => 'princess', 'lucca' => 'smart', 'frog' => 'honorable')); $fluent = new \Laravel\Fluent($data); // returns 'ordinary' echo $fluent->get('people.chrono'); // returns NULL echo $fluent->get('people.magus'); // returning a default value: returns "nobody knows, man" echo $fluent->get('people.schala', 'nobody knows, man'); In addition you can set values in interesting ways: $fluent = new \Laravel\Fluent(); $fluent->name('Locke'); // returns 'Locke' echo $fluent->name; It's interesting how much functionality you can get from such a small class. This is also a great opportunity to learn more about PHP's magic methods. Marco Monteiro wrote a great guide on this topic. The link to this post can be found below under extracurricular activities. **Our Goal For the Day** Create an object using Laravel's Fluent class then use and understand each function defined within the class (it's a very short class). Think about how you can use this class in your applications. **Required Reading** [Laravel's Fluent class](https://github.com/laravel/laravel/blob/master/laravel/fluent.php) **Extracurricular Activity** Learn and understand PHP's magic methods. [Official PHP Documentation on Magic Methods](http://php.net/manual/en/language.oop5.magic.php) [Marco Monteiro's Blog "PHP Magic Methods - The Complete Guide"](http://blog.marcomonteiro.net/post/33150811883/php-magic-methods)

#fluent class #magic methods #Laravel 3.2

Laravel's Helper Functions

Laravel comes stock with a collection of helper functions that are used to keep its code clean and expressive. We can use them for the same purpose in our own code. **Our Goal for the Day** Read the laravel/helpers.php file in its entirety. Understand each function and consider their potential use in your applications. **Required Reading** [Laravel's helpers.php](https://github.com/laravel/laravel/blob/develop/laravel/helpers.php) **Extracurricular Activity** Search the Laravel codebase to see how each of the helper functions are used within Laravel itself.

#helper functions #Laravel 3.2

Reverse-Routing with Controller Actions

Reverse-routing is generating URLs based on route declarations.

For example the following route declaration tells Laravel to execute the action "register" in the controller "users" when the request's URI is 'register'.

// http://mysite.com/register

Route::any('register', 'users@register');

Traditionally, we may link to the registration page like this:

However, this has the unfortunate disadvantage of being dependent on our route declaration. If we change the route declaration to:

// http://mysite.com/signup

Route::any('signup', 'users@register');

Then our link will be wrong. We'll have to go throughout our entire site and fix our links. Hope we don't miss one!

Instead, let's use reverse-routing.

Now, the link that we generate will automatically change when we change our routing table. In our first example it'd generate http://mysite.com/register. Then, when we change the routes call to match our second example it'll generate http://mysite.com/signup.

Reverse-routing can make your app not only more robust but easier to maintain. You're often more familiar with your controllers and actions than your URLs.

Your Goal for the Day

Use URL::to_action(), Redirect::to_action(), or HTML::link_to_action() at least one time today. Implement it, change a route, and see how it reacts.

Required Reading

Official Documentation

Laravel's URL class' to_action() method

Laravel's HTML class' link_to_action() method

Laravel's Redirect class' to_action() method

Additional Resources

Forum Post on Routing to Closures and Controller Actions as well as Reverse-Routing best-practices.

Screenr: Laravel 3 Controller Routing & Reverse Routing

#controller routing #reverse-routing #Laravel 3.2

Hi everyone! The good people of the #Laravel IRC channel came up with the idea to start a Laravel Study Group! We're exploring one discrete topic per day to increase our mastery of Laravel. Follow us here or at http://twitter.com/laravelio and check every week day for our new topic. Feel free to recommend topics [here on the official Laravel forum thread.](http://forums.laravel.com/viewtopic.php?id=3310).

Trending Blogs

Recently Viewed Blogs

Laravel.IO