Merge branch 'master' of https://github.com/tplaner/docs into hotfix/pivot-doc-improvements

Author: Shawn McCool

controllers.md

@@ -17,7 +17,7 @@
 
 Controllers are classes that are responsible for accepting user input and managing interactions between models, libraries, and views. Typically, they will ask a model for data, and then return a view that presents that data to the user.
 
-The usage of controllers is the most common method of implementingapplication logic in modern web-development. However, Laravel also empowers developers to implement their application logic within routing declarations. This is explored in detail in the [routing document](/docs/routing). New users are encourage to start with controllers. There is nothing that route-based application logic can do that controllers can't. 
+The usage of controllers is the most common method of implementing application logic in modern web-development. However, Laravel also empowers developers to implement their application logic within routing declarations. This is explored in detail in the [routing document](/docs/routing). New users are encouraged to start with controllers. There is nothing that route-based application logic can do that controllers can't. 
 
 Controller classes should be stored in **application/controllers** and should extend the Base\_Controller class. A Home\_Controller class is included with Laravel.
 

database/eloquent.md

@@ -303,6 +303,12 @@ However, you may often only want to insert a new record into the intermediate ta
 
 	$user->roles()->attach($role_id);
 
+If you ever find yourself wanting to add additional data into the intermediate table during an **insert** or **attach** you can do so very easily by passing an array of data as the second parameter for both:
+
+	$post->comments()->insert($comment, array('visible' => 1));
+
+	$user->roles()->attach($role_id, array('active' => 1));
+
 <a name="intermediate-tables"></a>
 ## Working With Intermediate Tables
 

models.md

@@ -48,7 +48,7 @@ Libraries and Models are very easy to use thanks to the Laravel auto-loader. To
 
 We've all head the mantra: "controllers should be thin!" But, how do we apply that in real life? It's possible that part of the problem is the word "model". What does it even mean? Is it even a useful term? Many associate "model" with "database", which leads to having very bloated controllers, with light models that access the database. Let's explore some alternatives.
 
-What if we just totally scrapped the "models" directory? Let's name it something more useful. In fact, let's just give it the same as our application. Perhaps are our satellite tracking site is named "Trackler", so let's create a "trackler" directory within the application folder.
+What if we just totally scrapped the "models" directory? Let's name it something more useful. In fact, let's just give it the same as our application. Perhaps our satellite tracking site is named "Trackler", so let's create a "trackler" directory within the application folder.
 
 Great! Next, let's break our classes into "entities", "services", and "repositories". So, we'll create each of those three directories within our  "trackler" folder. Let's explore each one:
 

routing.md

@@ -106,7 +106,7 @@ You are free to change this to fit the needs of your application!
 <a name="filters"></a>
 ## Filters
 
-Route filters may be run before or after a route is executed. If a "before" filter returns a value, that value is considered the response to the request and the route is not executed, which is conveniont when implementing authentication filters, etc. Filters are typically defined in **application/routes.php**.
+Route filters may be run before or after a route is executed. If a "before" filter returns a value, that value is considered the response to the request and the route is not executed, which is convenient when implementing authentication filters, etc. Filters are typically defined in **application/routes.php**.
 
 #### Registering a filter: