A) Composer (back to top...) 1) Do I Even Have Composer? (back to top...) To find out if you even have Composer installed, just run the following: composer Pretty simple. If you've got it installed, you'll get this: Otherwise, you'll just get $composer bash: composer: command not found 2) Composer Installation (back to top...) You'll use the Composer installer which will pretty much take care of everything. Don't worry about the "developer" option. Just install it and you'll be gold. That will create all the files and dependencies you need to start you new Laravel project. The only thing that you need to ensure is that when the prompt comes up that declares the PATH to your php.exe file - that path needs to be accurate. Provided that's in place, you'll be able to successfully call Composer from anywhere. And don't worry about a "proxy server." Just blow past that for now. Ran into a little problem with Composer when I first set it up. Wound up deleting it, reinstalling it and making a point of closing down the Command Prompt before attempting to set up a Laravel project. After that everything worked great. B) Laravel Installation (back to top...) 1) Laravel Version (back to top...) To determine what version of Laravel you're running, navigate to the directory where you've got your Laravel app and type this into your Command Line: php artisan --version Make sure you're in the directory where your Laravel application is located. Otherwise, you'll get a response that suggests you don't even have Laravel installed. 2) Installation (back to top...) To install Laravel, type this in your Command Line (again, shut down your Command Line app and open it up again to ensure that the Composer dynamic you just installed is recognized by Command Line as being present). That will install Laravel. Quit your Command Line interface and restart it. Type in laravel -h to see if you're running Laravel and if you get a screen that lists a number of Laravel commands, you're all set! Now you're ready to begin your project! You can also go out to https://laravel.com/docs/5.8 and copy and paste this line of code that you can retrieve from that site C) PHP Storm / Laravel Plugins (back to top...) You can install some "Laravel Helpers" that allow PHP Storm to fill in some gaps and make your coding a little easier. Do this by going to "File -> Settings" and navigate to "Plugins." Do a search for "Larvel" and install it. After that, you'll want to navigate to "File -> Settings -> Languages & Frameworks -> Laravel" and activate that plugin for your project (see image to the right). A) Set Up Directory / Install Laravel Infrastructure (back to top...) Use this command to set up your directory and the necessary files to kick off your project. B) Virtual Host (back to top...) What you're doing here is setting up your "virtual host" (localhost) in a way that resembles the manner in which your actual user is going to access your site. You've got to adjust two files to make that happen. The goal is to bring up the "blog" site in your "localhost" without having to type http://localhost/blog/public. We're going to change that so all we need to do is type blog.test. 1) Apache (back to top...) Right now, provided your WAMP was running, you could go to http://localhost/blog/public/ and everything would be running just fine. For the sake of this tutorial, however, we're going to adjust our Apache httpd-vhost.conf file to accommodate a more streamlined URL. Go to C:\wamp64\bin\apache\apache2.4.23\conf\extra and navigate to your "httpd-vhost.conf" file and add this line: 2) host file (back to top...) Now, open up a Notepad application and choose "Run as Administrator." Navigate to your C:\Windows\System32\drivers\etc and open up your host file. You'll most likely have to choose the "Show All Files" option in order to see it. Add this line: 127.0.0.1 blog.test. Restart Apache and you should be gold! All you need to do is head out to "blog.test." The first page you're looking at is based off of the routes/web.php file which has this: Route::get('/', function () { return view('welcome'); }); That's opening up the welcome.blade.php page that sitting in resources/views. "blade," by the way, is the template engine that Larvavel uses. A) app (back to top...) 1) Console (back to top...) This is where you'll store your Console commands will live. You won't be using this directory that often. 2) http (back to top...) a) Controllers (back to top...) This is where your logic lives as per your typical MVC architecture. b) Middleware (back to top...) Middleware is the home for that code you may want to execute before the looks in the Controller directory. A good example would be any kind of authentication you want in place. B) bootstrap (back to top...) This is where you're going to keep your "cache" file. C) config (back to top...) This is what you would expect, as far as you "config" settings. An example would be your "database.php" file which has all the settings you would want access to in order to connect with any one of a number of database types. D) database (back to top...) "migrations" let you manage your database structures. "factories" and "seeds" allow you to do "en masse" operations. We'll get into that more later. E) public (back to top...) This is your root directory and the only place that's accessible to the client browser. F) resources (back to top...) 1) assets (back to top...) The "assets" directory is where you'll keep all of your JavaScript code that needs to be compiled. 2) lang (back to top...) "lang" is where you'll put your translated words if you're building a multi-language site. 3) views (back to top...) Here's your "home" for all of your "views" - what your user is going to "see." G) routes (back to top...) The only file you need to worry about right now is "web.php." This is where you're going to put your main "routing" for your site. H) storage (back to top...) The only directory you need to concern yourself with for right now is the "logs" directory. That's where you're storing your system error logs. I) tests (back to top...) This is where you'll keep your unit and functional tests. We'll get into that more later... J) vendor (back to top...) Here's where you're keeping all of your supplementary tech. You'll never edit anything in here. K) env (back to top...) "env" is a file you want to remember in that it's here where you define all of your database constants. "database.php" is the code, but "env" is where you store your values. A) web.php (back to top...) This is your primary / go to route. Let's pop the hood on it and see where it leads: Route::get('/', function () { return view('welcome'); }); This is going to be your "index" page. You'll see that it shoots you to the "welcome" view. This is the "welcome.blade.php:" Get it? Now, as a rule, you don't want to use "logic" code to return a basic view. You're better off writing this in your "web.php" page: Route::view('/', 'welcome'); B) PublicController.php (back to top...) Instead of using the "view" approach right out to the box, let's route things to a Controller and then, from there, direct it to the View. First, create a Controller using your Terminal: Here's your route that references the Controller: Route::get('/', "PublicController@index"); ...and now, here's our "PublicController" with the "index" function that returns the "welcome" view: <?php namespace App\Http\Controllers; use Illuminate\Http\Request; class PublicController extends Controller { public function index() { return view('welcome'); } } C) Groups (back to top...) This is a great way to organize your routes according a particular URL. For example, all of your "blog/admin" routes could be grouped like this: D) Passing Parameters in Your Routes (back to top...) 1) Single Parameter Using a Route (back to top...) To pass a parameter to your page using your Routes, you would do this: Route::get('user/{userId}', function($userId){ return 'user id: ' . $userId; }); So, if your URL is "http://blog.test/admin/user/1," that will give you this: 2) Single Parameter Using Controller (back to top...) You can also do the same thing using your Controller. Here's your Route: Route::get('user/{userId}', 'PublicController@userInfo'); ...and here's your Controller: public function userInfo($userId) { return "User ID: ".$userId; } Same result as before. Finally, if you wanted to pass multiple variables in through your URL, you would do this: 3) Multiple Parameters Using Controller (back to top...) Here's your Controller: public function userInfo($userId, $name) { return "User ID: ".$userId. '-' . $name; } ...and here's your Router: Route::get('user/{userId}/{name}', 'PublicController@userInfo'); E) Namespaces (organizing your Controllers) (back to top...) Right now you only have one Controller. That can get pretty cumbersome pretty quick. To break things up a bit so you can keep your code from getting out of control, you use "namespaces." 1) Create Controller (back to top...) Start by creating another Controller. Call it "UsersController.php." Now, create another directory in your "Controllers" folder and name it "Admin" and move your new Controller to that directory (see image to the right). 2) Create Route (back to top...) Here's your Route: Route::prefix('admin')->group(function(){ Route::get('users', 'Admin\UsersController@listUsers'); Route::get('posts', function(){ return "admin posts"; }); Notice the fact that it has an "address" and the fact that the "\" is a backward slash. You can't use a forward slash. a) Namespace Route Shortcut (back to top...) You can also do this: Route::namespace('Admin')->prefix('admin')->group(function(){ Route::get('users', 'UsersController@listUsers'); Route::get('posts', function(){ return "admin posts"; }); Notice the addition of the namespace dynamic. Plus, you don't have the "Admin" entity like you did before... Here's what it was: Route::get('users', 'Admin\UsersController@listUsers'); Here's what you've got now: Route::get('users', 'UsersController@listUsers'); A neat little way to keep things organized without having to document the namespace over and over again... 3) Document Namespace and "use" (back to top...) ...and here's your Controller: <?php namespace App\Http\Controllers\Admin; use Illuminate\Http\Request; use App\Http\Controllers\Controller; class UsersController extends Controller { public function listUsers() { return "list users = admin/users controller"; } } Notice the way the "namespace" is documented and the way "use" is referenced as well. And that will do it! F) Route Names (back to top...) Hardcoding a specific URL isn't necessarily a good idea, especially if you wind up changing your domain. You can "name" your routes so you don't have to worry about specifying a particular domain. Here's how you do it: Route::get('/', "PublicController@index")->name('welcome'); //here I'm naming my route Route::get('posts', function(){ return route('welcome'); }); Now, when I go out to "http://blog.test/admin/posts," I get this: ...and that makes sense because the whole route is based on "/"... 1) Passing a Variable (back to top...) If you had to pass a variable through your route name, you would do it this way: Here's your "web.php" page: Your Controller looks like this: public function index($name) { return view('welcome'); } So, now when you go out to "http://blog.test/admin/posts," you get this: 2) Passing Multiple Variables (back to top...) i) Route (back to top...) To pass mulitple variables, you use an array configuration. Here's your Route: ...and then your page looks like this: Notice that you don't have to worry about your Controller, as far as populating the Route with content. G) Redirect (back to top...) Easy - peasy... Route::redirect('/old', '/new', 301); A) Create Middleware (Terminal Command) (back to top...) To create your Middleware functionality, type this into your Terminal: B) Register Middleware (back to top...) 1) Kernel.php (back to top...) In your "Http" directory, you've got a file called, "Kernel.php." Here's where you're going to register your Middleware. You've got more than one option. The one we're going with in this case is the one that allows you to assign it to a group or an individual route: 2) web.php (routes) (back to top...) Now, assign it to your route... Route::get('users', 'UsersController@listUsers')->middleware('checkAge'); Now, when you put this in your URL: http://blog.test/admin/users?age=25 ...you get this page: D) Assign Middleware (back to top...) Previously, you assigned some Middleware to a specific route. You can also assign it to a Controller which will affect multiple routes. You just put it in the corresponding Controller. In this case, we're altering the "UsersController.php." A) Set up Your Database Connection (back to top...) To set up your database connection, you're going to go to your "env" file and do this: DB_CONNECTION=mysql DB_HOST=127.0.0.1 DB_PORT=3306 DB_DATABASE=blog DB_USERNAME=root DB_PASSWORD= That's your "blog" database with the necessary credentials. B) Migration (back to top...) Alright...what's a "migration?" Here's the definition from the Laravel docs... Here's the way it looks in real life. The command is create_posts_table "posts" is the name of your table. That's the first part of the command. The second part is what you see, as far as the --create posts. With this command, you're not just creating a table, you're doing it in a way that's documented so other people working on the same app are alterted to what you've done. After you do that, you'll see a record of that in your database->migrations file. It looks like this: "up" is what's triggered when you execute the migration, "down" is when you want to roll things back. ① this is the syntax you use to create a default value Now, having created your "migration" dynamic, all you need to do now is run: ...and just like that, you're table is created along with another table that documents your migrations. Pretty cool! And, if you want to roll all that back, all you need to do is: ...and that will kill your "posts" table. C) Migration Functions (back to top...) 1) Change Column Name (back to top...) You can use your terminal to rename columns in your database, although you need a new package to do that. Using "composer," you'll type this into your terminal: \Once that's installed, you'll do this: Understand, this is just manufacturing a "migration" doc. This doesn't actually change the name of the column. To do that, you've got to go to the newly formed migration file named, "rename_content_to_body." Once you're there, you'll add this syntax: Now when you do this: That will change the name of the column, "content" to "body." 2) Change Default Value (back to top...) You can change the default value of your column by first creating your migration file... ...and then entering the highlighted syntax to that new migration file: C) Models (back to top...) With Laravel you can create your Model right out of the chute that will interact with the table that you name it after. Like this: The name "Post," will automatically assume you're going to be interacting with the "post" table. D) Seeders, Factories and Faker (back to top...) 1) Factories (back to top...) Factories are a feature that Laravel provides to help you test your data. You start by using your Terminal to create a "factory" file: Once it's made, you'll document the code like this in your new file: 2) Seeder (back to top...) Now, create your "seeder" file: Now, once that file has been created, here's the code: ① this first line is saying, "Create a 'post' function that will insert 10 rows. Each of those rows will be... ② a saved "issue" that's associated with each of the created posts. In order to get our "seed" class recognized, we'll need,"dump autoload" which you'll install via Composer: At this point, you're going to use the "DatabaseSeeder.php" page to "seed" your database. You can document things on the actual php page, or you can do it via the Terminal like this: And that will populate your database with 10 rows of dummy data! A) Master View (back to top...) First, you've got your "web.php" which is your "route" configuration: The highlighted "welcome" route is what's triggered when your user hits the index page ('/'). When you go to the "welcome.blade.php" page, you see this: ① @extends('Layouts.master') is the code you're using to tell the system to "include" the code that's coming from your "views/layouts/master.blade.php" file. Notice the convention as far as what's capitalized and what is written in lowercase etc. ② @section('content') is the content that's specific to this particular page. B) Passing Variables (back to top...) This is pretty cool. To pass a variable into your view, you're going to start by adjusting your "web.php" page and configure your route to your index page like this: //Route::view('/', 'welcome'); Route::get('/', 'PublicController@index'); Route::view('/about', 'about'); Instead of calling a "view" right out of the chute, we're going to call the PublicController and we're going to be looking for the "index" method. That looks like this: ① we start by declaring a variable which, in this case, is "title." Then we give it a value. ② we use the "compact" function to grab and send the variable to the "welcome" view. Finally, on the "welcome.blade.php" page, we've got this: You can also pass HTML code into your $title element by doing this: Here's your Controller: <h1>Muscular Christianity</> ...and then on your "welcome.blade.php" page, you'll have this: {!! $title !!}. Strange, but it works! Here's the thing: While you can pass HTML into your views, a more secure way of doing it would be like this: Here's you Controller: ...and here's your "welcome.blade.php..." <div class="title m-b-md"> {{$mainTitle}} </div> C) Passing Variables Globally (back to top...) You can pass variables globally as well. You start with your AppServiceProvider.php page in your app/providers directory 1) AppServiceProvider.php ① make sure you add this package at the top ② this is the code that passes your variable Now, when you go into any of your "blades," you can do this: <div class="title m-b-md"> {{ $title }} </div> 2) .env file (back to top...) Another way to pass global variables, like the title, is to use your .env file which is located in your home directory. APP_NAME=Laravel APP_ENV=local APP_KEY=base64:oe3Ry9cOza5diYON16y9DlUbVDQu8/uIMzU7rODrrNE= APP_DEBUG=true APP_URL=http://localhost And then you reference that in your "AppServiceProvider.php" page like this: public function boot() { View::share('title', env('APP_NAME')); } D) Loops (back to top...) This is your PublicController.php: ...and then we head out over to our "welcome.blade.php" page and we do this: <div class="content"> @foreach($posts as $post) <li>{{ $post }}</li> @endforeach </div> ...and that's that! E) Includes (back to top...) To demo includes we're going to create a "navigation.blade.php" page with some links: <div class="top-right links"> <a href="#">Welcome</a> <a href="#">About</a> </div> ...and then you reference that on your "master.blade.php" page like this: @include('includes/navigation'); F) Helpers / Active Links (back to top...) We're going to use a shorthand "IF" block to establish the style of the links based on the route name... <div class="top-right links"> <a {{ Request:: route()->getName() == 'welcome' ? 'style=color:red;' : ''}} href="{{ route('welcome') }}">Welcome</a> <a {{ Request:: route()->getName() == 'about' ? 'style=color:red;' : ''}} href="{{ route('about') }}">About</a> </div> A) contact.blade.php (back to top...) Here's our "contact.blade.php" page: ① this is your route ② with this one little piece of code, you're adding a hidden field with a CSRF token B) Route (back to top...) Here's your route: Route::post('/contact', 'PublicController@contactPost')->name('contactPost'); The name of the route is "contactPost," the method it will be looking for on the PublicController is "contactPost." C) PublicController (back to top...) public function contactPost(Request $request) { var_dump($request->all()); } 1) Single Field (back to top...) To retrieve a single field, you would do this: public function contactPost(Request $request) { //var_dump($request->all()); //var_dump($request->input('name')); $name=$request['name']; var_dump($name); } D) File Upload (back to top...) 1) File Upload Field (back to top...) Once again, Laravel doesn't fail to impress with how much code you can write with just a little bit of syntax. <div class="form-group"> <input class="form-control" type="file" name="attachment"> </div> Of course, you don't want to forget to alter your form by including the "enctype..." <form method="Post" action="{{ route('contactPost') }}" enctype="multipart/form-data"> 2) Controller (back to top...) Here's the way your Controller will look like when you're simply returning the original name of the file: public function contactPost(Request $request) { if($request->hasFile('attachment')) { $file = $request->file('attachment'); echo "File Name " . $file->getClientOriginalName(); } else { return "no"; } $name=$request['name']; var_dump($name); } ...and here's how it's going to look when you actually move the file to a specific directory: ① see if you've got a file ② save the file itself in a variable called $file ③ grab the file name using the funciont getClientOriginalName ④ move the file to a directory called, "images" E) How to Handle an Array of Inputs (back to top...) Imagine you've got more than one email field. How do you handle that kind of scenario? For example, on your "contact" form you have both a personal email and a work email field... <div class="form-group"> <input class="form-control" type="email" placeholder="Personal Email" name="email[]"> </div> <div class="form-group"> <input class="form-control" type="email" placeholder="Work Email" name="email[]"> </div> Notice how you have the name of each field coded as "email[]." Now, when you retrieve those through you Controller, it will look like this: Now, when you do a data dump based on the highlighted code, you get this: 0 => string 'bruce@brucegust.com' (length=19) 1 => string 'brucegust@gmail.com' (length=19) If you wanted to retrieve just the personal email, you would do this: $name=$request['email']; var_dump($name[0]); A) Basic Setup (back to top...) You're going to start by navigating to your home directory in your Terminal and typing in the "laravel new personal-blog." Notice this is different from the first project we set up in that we used Composer. But since Laravel is already installed, we can go this route. After that, you're going to want to configure your browser so it automatically goes to the correct home page.

• configure your Apache server
• configure your host file

B) Import Front End Assets (back to top...) You can download an entire look and feel for free without having to start from scratch. BOOM! Head out to https://startbootstrap.com/themes/creative/ and download the zip file. Copy and paste all of the files into your "assets" directory. Then delete everything except the css, img, js and vendor folders. Grab the HTML code that is rendered when you go to "personal.blog/assest/index.html." Copy that into your "welcome.blade.php" page and then add "assets" to the appropriate URLs so your page renders correctly. Like this: You'll do that for all your CSS and JS directories. C) Create Other Pages (back to top...) 1) Create Route (back to top...) Start by creating your Route... Route::get('/', function () { return view('welcome'); }); ...becomes this: Route::get('/', 'PublicController@index'); 2) Create PublicController (back to top...) Since you don't have a PublicController file yet, you need to start with this: After you make that Controller, add this code to accommodate your page... class PublicController extends Controller { public function index() { return view('welcome'); } } 3) Create View (back to top...) You've already got the "welcome.blade.php" view page, so you're set. To add new pages, you'll repeat the above process sans the creation of the PublicController... You can get those pages by heading out to the following links:

• post
• contact
• about

This is great, but if you were to look at the pages, you'll notice that the C SS is all squirreled up. To remedy that, we're going to create a "master.blade.php" page that will provide all of the CSS / layout dynamics that we need that we can then easily apply to all of the pages. 4) Create master.blade.php (back to top...) This is your "master.blade.php" page: You created a new directory in your "views" folder and named it "layouts" and then put your "master.blade.php" page in that folder. Your "welcome.blade.php" page went from this: ...to this: ① extend your master layout paradigm ② define your content (this is going to be referenced on your "master.blade.php" page which we'll see in a moment ③ close your "content" section And this is your "master.blade.php" page: Notice that "assets" was altered by adding a "/" character. That makes a difference when you're dealing with URLs that have multiple layers. An example of that would be "post/1." That's the URL we're contending with when we hit "post/1." Altering our "assets" in our "master.blade.php" page will take care of that. Look at the highlighted "@yield('content');" element. That's the way you're telling your "master.blade.php" page to be looking for a section called "content" in any page that constitutes and extension of the "master.blade.php" D) Asset Helper (back to top...) All your assets now are currently referenced as relative URLs. You can change them into Absolute URLs by using the Laravel "asset helper." To start with, you'll do this in your "master.blade.php" page: <script src="{{asset ('assets/vendor/jquery/jquery.min.js')}}"></script>< ...and then for all of your images, you'll do this: <header class="masthead" style="background-image: url('{{asset ('assets/img/post-bg.jpg')}}"> Notice that you still have to include the "assets" directory in the URL that pertains to both your JS, CSS and image files. E) Authentication (back to top...) Start by setting up a database using PhpMyAdmin and then adjusting the login criteria in your ".env" file: DB_CONNECTION=mysql DB_HOST=127.0.0.1 DB_PORT=3306 DB_DATABASE=personal-blog DB_USERNAME=root DB_PASSWORD= Next, head out to your "AppServiceProvider.php" page and make the following changes: After that, using the terminal, type in... This will create your migration. To run it, do this: That will create your tables! In addition, it will set up your Authentication Controllers, Middleware and Views! It's beautiful! E) Authentication (back to top...) 1) mailtrap.io (back to top...) We're using mailtrap for the sake of establishing an email paradigm that we can use to test the whole resetting of one's password. F) Navigation (back to top...) 1) navigation.blade.php (back to top...) Grab the navigation content from "master.blade.php" and paste it into a new file called "navigation.blade.php" and put that in a new directory called "includes" within your "views" folder. After that, put this code in your "master.blade.php" page: @include('includes.navigation') 2) web.php (back to top...) Give each of your links a name in your "web.php" page: 3) Authenticated Links (back to top...) To create a situation where some links are visible only when a particular user has been authenticated, here's what you do on the "navigation.blade.php" page: After you get that done, you're going to have to change the way certain pages reference "/home" in their code. You'll do that with: ResetPasswordController.php RegisterController.php RedirectIfAuthenticated.php LoginController.php BTW: Don't edit anything in the "vendor" folder. And that will do it! G) Admin Panel Assets (back to top...) We're going to use a Bootstrap template to create what will amount to a very nice looking admin suite. We're going out to startbootstrap.com to download a zip file. Once it's downloaded, you're going to copy the "assets" folder that's located in the "src" directory and paste that into a new folder in your application. Under "public" create a new folder called "admin" and in that folder, place the "assets" folder you copied a moment ago. You're poised on the threshold of great things! 1) AdminController (back to top...) Create a new Controller that will facilitate all of the admin views that we're going to need. Now create a "dashboard" method that will direct the user to the "dashboard" blade. class AdminController extends Controller { public function dashboard() { return view('admin.dashboard'); } } 2) Admin Route (back to top...) In your "web.php" page, do this: Route::prefix('admin')->group(function() { Route::get('/dashboard', 'AdminController@dashboard')->name('adminDashboard'); }); That gets your "dashboard" concept into place. Now let's create that view... 3) Dashboard Blade (back to top...) Under your "views" directory, create another folder called "admin." This is where you're going to store all of your admin views. Once you've done that, create a new file called, "dashboard.blade.php." For now now just write the word, "Hi." Now, when you go out to http://personal.blog/admin/dashboard, you'll see your page. H) Protecting Admin Panel (back to top...) 1) Create, Register and Run CheckRole Middleware (back to top...) a) Create CheckRole (back to top...) We're going to start by creating a new Middleware called "CheckRole." b) Register CheckRole (back to top...) After you've done that, you have to register it in the "Kernel.php" file which is located in the "http" directory. That's going to look like this: BTW: Kernel is the central part of an application's operating system. With Middleware, generally you want it to fire with every request. So, you need to register it in the "kernel.php" file. c) Run CheckRole (back to top...) Add this to your "AdminController" page to ensure that the "CheckRole" middleware is running... public function __construct() { $this->middleware('checkRole: admin'); } 2) Edit CheckRole Middleware (back to top...) When you created "CheckRole," that put a file in your "http->Middleware" folder. The file looks like this: ① You need to make sure you're bringing the "Auth" package into the mix since you're referring to that as part of your "CheckRole" class. FYI: "Illuminate" is part of how Laravel names its components. Click here for more information. ② checking first to see if the user is logged in at all. ③ Now looking to see if the user has "admin" permissions. The "admin" value is part of the "users" table that we added when we introduced the "auth" dynamic that we created with php artisan auth. I so dig that! I) Login Page (back to top...) You're downloading a free Bootstrap admin template that gives you some great features and asthetics right out of the box. Start by going out to StartAdmin-Free-Bootstrap and download the zip file. After you've downloaded it, you're going to retrieve the contents of the "assets" directory and install all those in a new folder you're going to create in the "public" folder of your project. Create another folder called "admin" and in that directory, create another folder called "assets" and put the content of the "assets" folder you just downloaded and put all of that content in the "assets" folder you just made. Once that's done, now you're going to the log "login.html" file in "src->demo_1->pages->samples and get all of the aesthetic settings. It will look like this - you're getting the higlighted stuff... What's happening is that that you're grabbing all of the aesthetic bells and whistles and then just dropping into the section that's not highlighted your original form that now has some new CSS attached to it. 1) auth.blade.php (back to top...) What you're going to do now is take all of that highlighed content and drop it into a new file that will go into your "layouts" directory. We're going to call it "auth.blade.php" and it will look like this: The @yield('content') is the darling piece of this code in that it is telling the system to "yield" to the code that's going to be coming into the page that we're calling "content." Check it out: 2) login.blade.php (back to top...) Notice how we're calling our login html and code content "content." That's what's going to allow the "auth.blade.php" file to correctly accept and display the supplementary code coming from this file. J) Dashboard (back to top...) Grab the "index.html" from your Bootstrap template and put that in a new file in your "layouts" folder. Call it "admin.blade.php." After you do that, you'll want to find where the main content is going to be located and put, " @yield('content')" at that point. Now, go to your "views" directory and grab your "home.blade.php" file and rename it to "dashboard.blade.php." Once you do that, you'll want to adjust your "HomeController.php" file so it's referring to "/dashboard" rather than "/home." Also, change the layout you're referring to at the top of the page to "@extends('layouts.admin')." And that will do it! K) Dashboard Navigation (back to top...) First thing is get rid of the two <li> elements that form the email and notification icons / pulldown menu. 1) Login Name (back to top...) Next, you're going to replace the static "name" with the name of the hardcharger that's logged in with this: <p class="mb-1 mt-3 font-weight-semibold">{{ Auth::user()->name }}</p> 2) Sidebar Links (back to top...) You're going to change up the sidebar somewhat with a different class for you links as well as some additional icons. The class you're going to use is this: a.new_menu_link { color:#ffffff; align-items:center; padding:15px 30px 15px 25px; whitespace: nowrap; height:52px; font-size: 15px; font-weight:bold; font-weight:500; display:inline-block; display:flex; } This is on your "sidebar.css" page. Your links are going to look like this (with your icon): <li class="nav-item"> <a href="index.html" class="new_menu_link"> <ion-icon name="md-document" lazy="" role="img" class="hydrated" aria-label="person" style=font-size:18pt;"></ion-icon>   <span class="menu-title">Courses</span> </a> </li> Notice the new class! And, for your icons, you're going to need a new JS code. You'll put that on your "admin.blade.php" page... <script src="{{ asset('admin/assets/vendors/iconfonts/ionicons/ionicons.js') }}"></script> And for the actual icons, you can click here for a reference. Your finished sidebar menu looks like this: The highlighted section represents a very cool pulldown that I want to keep in mind... 3) Sidebar Links (back to top...) You're going to copy and paste the logout code from your "navigation.blade.php" page. The finished logout code on your "header.navigation.blade.php" page will look like this: <form method="Post" id="logout-form" action="{{ route('logout') }}">@csrf</form> <a class="dropdown-item"onclick="document.getElementById('logout-form').submit();" style="cursor:pointer;">Sign Out<i class="dropdown-item-icon ti-power-off"></i></a> </form> L) Creating, Migrating, Seeding...Posts and Comments Table (back to top...) Several commands, most of which we've already gone over, but here's some of what happened... M) Displaying Posts & Comments (back to top...) 1) Dynamic Title (back to top...) In your "header," you'll want to change it to this: <title>@yield('title', 'Laravel Blog')</title> That tells Laravel to "yield" to whatever the "title" variable may be and print that. If there's no "title" variable, then write "Laravel Blog." 2) welcome.blade.php / Post.php / Public Controller (back to top...) Here's what your "welcome.blade.php" page will look like: Now, a lot of this isn't going to make sense without the "Post.php" Model and the Public Controller, so let's bring those puppies to the screen. You'll see things color coded so as to reference what code goes with what function etc. Posts Model Public Controller ① the "foreach" dynamic is going to loop through all of the "posts" belonging to this user. The blue square is the symbol that shows which part of the Model and the Controller go with this particular syntax. You'll notice in the "Public Controller," you've got this: $posts = Post::all(); return view('welcome', compact ('posts')); The highlighted part is what was added. You've got the first part which amounts to a "select all" and then you're passing that array into your "welcome" view with the "compact('posts')" script. Nice! ② {{$post->title }} works because "post" is your variable that you set up in the "foreach" statement and you're grabbing the "title" part of that array which is coming from your "posts" table. ③ {{$post->user->name}} works because of the JOIN / relationship you set up in the "Post.php" model. You can see it to the right of the red square. This... public function user() { return $this->belongsTo('App\user'); } ...sets up an INNER JOIN between the "posts" table and the "users" table. That's how you can now access the user that authored every post. ④ on {{ date_format($post->created_at, 'F d, Y') }} - that's the date coming from the "posts" table combined with the necessary syntax that coverts the date to something pretty. ⑤ this syntax may be starting to look familiar because of the way it's structured. Sure enough, you've got another relationship happening here which was set up in the Model: public function comments() { return $this->hasMany('App\Comment'); } ...and that's why {{ $post->comments->count() }} works. N) Displaying Single Post & Comments (back to top...) First, you've got your route... Route::get('post/{id}', 'PublicController@singlePost')->name('singlePost'); Then you've got your Controller: public function singlePost($id) { $post = Post::find($id); return view('singlePost', compact('post')); } You're grabbing the post that matches the $id coming from the "find" function and then passing that array of "stuff" into the view. This is your "singlePost.blade.php:" A) Setting Up the Project and Shortcuts (back to top...) 1) composer create-project (back to top...) This is going to be a whirlwind tour based on two videos. The first one shows you how to set up an API in Laravel. The second shows how to take all that knowledge and incorporate Vue.JS so you can build a single page application. Here's the way you're going to set up your API. Navigate to the directory you want to install your new project. So, if you're in your root directory and you plan on having a project in a "new_project" folder, then you're exactly where you need to be if you're in your root directory. Don't create another folder named, "new_project." Otherwise, you're going to have a folder in your "new_project" directory called, "new_project." Once you're good to go on that score, enter this on Git Bash: BTW: --prefer -dist is, "...--prefer-dist: Reverse of --prefer-source, composer will install from dist if possible. This can speed up installs substantially on build servers and other use cases where you typically do not run updates of the vendors. It is also a way to circumvent problems with git if you do not have a proper setup." Basically, it's going to let you speed up installation. This sets up all your packages, libraries and dependencies. After that, set up your shortcuts based on the "clunky" URL of "localhost/pages/public/index," You can review those steps by clicking here. 2) database / .env file (back to top...) Setup your database in phpMyAdmin. In this case, we're going to call "pages_database" and set things up accordingly in the ".env" file. DB_CONNECTION=mysql DB_HOST=127.0.0.1 DB_PORT=3306 DB_DATABASE=pages_database DB_USERNAME=root DB_PASSWORD= 3) migration (back to top...) You'll be using "migrations" and "seeds" to create and populate your tables so that's all you have to do at this step. i) create migration file / adjust AppServiceProvider (back to top...) When you create that file, you've created, not only the syntax that will create your table, but you'll also create what another developer will need in order to mimic your set up if that becomes an issue. After you've done that, you'll see the file you just created in app -> database -> migrations. It's just "scaffolding," though. You've got to add the fields that are specific to your app. In this case, it looks like this: What was added in seen above in bold. To start off with, go to app -> Providers and open up "AppServiceProvider.php." Add the syntax you see in bold below: That prevents the "length" error from occuring. ii) create seeder file (back to top...) To create your "seeder" file, do this: After running that, you get the "ArticlesTableSeeder.php" file in the "app -> seeds" directory: What this is doing is specifying the Model, which is going to be in your "app" directory. The Model hasn't been made yet, but we're getting there. When it is put in place, this "seeder" will be pointing to it. The highlighted section is something you may have to be aware of because it references it as a "Model" right out of the chute. iii) Adjust DatabaseSeeder.php File (back to top...) Go to your "DatabaseSeeder.php" file in your app -> database -> seeds directory and adjust it according to what you see in bold below. iv) Make Article Factory (back to top...) Thus far you've...

• made your migration file
• created your Model
• created your seeder...

...now, you're going to create your "factory." Go to app -> database -> factories to see the file you just created. You'll see something like this (the code's been altered according to what you see in bold below); v) Make Model (back to top...) Time to make our Model. To do that, you'll run this code: That gives you this file: vi) Create Tables (back to top...) In one fell swoop, we're going to create all of our tables by doing this: That makes all of our tables. The next step is to populate them with some data... vii) Add Dummy Data (back to top...) Now, we're going to create some dummy data in our "articles" table. What this is going to do is run any "seeder" file you've got in your "seeds" directory. Notice the convention when it comes to naming tables. In this case, you're populating a table called, "articles." In our "migration" file, you're going to refer to that table as "article..." factory(App\Article::class, 30)->create(); That gives us 30 rows of dummy data that we can now use as a way to test the functionality we're going to create to administer our site's content. B) Setting Up Controllers and Routes (back to top...) 1) List Articles (back to top...) i) ArticlesController.php (back to top...) Start by making your Controller that's going to "control" your "articles" table: By adding "resource," it will automatically generate placeholders for your main blocks of functionality. Here's your finished Controller: ① you're going to need this as part of being able to process requests coming from headers etc. ② Establish a variable where you can store your list of rows coming from the "Article" model. You'll add some additional syntax that give you the automatic pagination simply by invoking that one command! ③ here's where you're going to use a Laravel feature called "Resource," which makes for a very streamlined approach to retrieving a list of rows from a table in a JSON format. Here's the definition as it's coming from the Laravel docs: In this case, you're working with the "Article" model. You define your "dependency" at the top of the page and name it "ArticlesResource" and then invoke it in your code and pass the "article" variable into it via the paranthesis. ii) api.php (routes) (back to top...) iii) Resource (back to top...) This was already mentioned in the "ArticleController" section and, from that perspective, it's out of order. With the RESTful dynamic, you want something that serves as a liason between your Model and your Controller so you're able to retrieve your data in a JSON format. You're going to actually add this to your app with this command: That's the file that you see in the, "http->Resources" directory which looks like this: ① this is the only real "edit." This is all straight out of the box in that return parent::toArray($request); gives you an array of the entire column set. This piece of syntax: return [ 'id' => $this->id, 'title' => $this->title, 'body' => $this->body ]; ...is what gives you the opportunity to specify what column names you want to receive from the database. iv) Postman / API in Action (back to top...) Let's use Postman and see this in action! In Postman, we're going to do this: pages.site/api/articles That's going to trigger the route, Route::get('/articles', 'ArticleController@index'); and that's going to put in motion this guy, right here: public function index() { //get articles $articles = Article::paginate(15); //return collection of articles as a resource return ArticleResource::collection($articles); } See the above, "exploded" view of the Controller to see all of the syntax explained in more detail. Because of the pagination, we get 15 rows as well as the syntax we need to have in place to trigger the page that will give us the next 15 rows! See the highlighted section below. 2) Display Article (back to top...) To display a single article, you're using this code in your Controller: ① your $id is coming from your route: Route::get('/article/{id}', 'ArticleController@show'); ② "findOrFail..." ③ this is yet another use of your "resource" that Eloquent uses for API dynamics When you go to Postman and do a "POST" using http://pages.site/api/article/4, you get this: Notice how your object is wrapped in a "data" key. If you want to remove that part of what's being returned, you got to AppServiceProvider.php in your Providers directory and add what's highlighted below. When you do that, you get this: Notice now you don't get the info wrapped up in a "data" object. You can also add information to what you're getting back from the database by altering your Resource Article.php file like this: Now, you'll get this from your "display" code: { "data": { "id": 4, "title": "Updated Tite", "body": "updated body" }, "version": "1.0.0", "author_url": "http://brucegust.com" } Bear in mind that when you do this, regardless of how you edited your "AppServiceProvider.php" page, you'll still get everything wrapped up in your "data" object. BTW: You can get into what represents a bit of standard for JSON API development. You can read all about it here. 3) Add / Edit Article (back to top...) To add or edit an article, you're going to use your "store" function on the "ArticleController.php" page. ① this is an IF statement that's asking whether or not your app is using the "PUT" method and, if so, it's invoking the "findOrFail" method. If that is the case, it's grabbing the "article_id" from the page. Real quick, here's a summary of the "ternary" IF construction: As you can see in the above syntax, ternary operator includes three parts. First part (before ?) includes conditional expression that returns boolean value true or false. Second part (after ? and before :) contains a statement which will be returned if the conditional expression in the first part evalutes to true. The third part includes another statement which will be returned if the conditional expression returns false. Also, as a quick aside, Article is your "Article" model which you imported into your Controller with this line of code: use App\Article; So, in this one ternary IF statement you're saying that if the app is using a "PUT" dynamic, you're going to use the "findOrFail" method and passing the value of the article_id into the method. Otherwise, you're setting up an entirely new "Article" object. ② Having defined whether or not this is an entirely new entry or you're merely updating an existing record, once the user hits "save," you grab the incoming data and process it by passing your object into your new "resource" object. To update an article then, your Postman interface is going to look like this: You're going to use the PUT method and your URL is "http://pages.site/api/article." The system recognizes PUT and then looks for the id of the already existing record. In our Postman interface, we put "content type" of "appplication/json" in our header and then put row JSON code into our body that looked like this: { "article_id": 4, "title": "Updated Tite", "body": "updated body" } And that updated our article. To put a new article into the database, we used the same "application/json" content type and then this will be the raw JSON in your body: { "title": "Test Title", "body": "test body" } You'll use the URL, only this time you're using "POST" instead of "PUT" and that's all there is to it! 4) Delete Article (back to top...) To delete an article, you're going to start by coping the code you had in "show" and making a couple of modifications. ① start by finding your article with "findOrFail." ② if the request is a "delete," then system knows to delete that from the database AND send back the information that you just thew in the trash can. Remember that your route needs to be this: Route::delete('/article/{id}', 'ArticleController@destroy'); You've got your "id" in the route and "article" is singluar. C) Vue.js (back to top...) This was a real mess at the beginning. Even after getting some apparent deficiencies addressed, anytime I went to run npm run watch, I got this error: In the end, it was a wild goose chase that was finally solved by running the above commands (composer require laravel/ui --dev | php artisan ui vue). Short of that, and it was a mess that never stopped. 1) Install Dependencies and "npm run watch" (back to top...) i) Bringing Files from One Project to Another (back to top...) When you're bringing files from one project to another, you'll copy and paste your Controllers and your Routes. One thing that might be a little illusive, however, is your Models. Those are sitting in your "app" directory and are absolutely essential in order for your Controller to work in the context of your database. ii) package.json (back to top...) You'll run npm install to get your localized app up to speed with all of the Node related dependencies in place. In your "package.json" file, you have this: "devDependencies": { "axios": "^0.19", ❶ "bootstrap-sass": "^3.3.7", "cross-env": "^5.1", "jquery": "^3.2", ❷ "laravel-mix": "^4.0.7", "lodash": "^4.17.13", "resolve-url-loader": "^2.3.1", "sass": "^1.15.2", "sass-loader": "^7.1.0", "vue-template-compiler": "^2.6.10", "vue": "^2.5.7" } A couple of things you'll want to be aware of... ① SASS stands for "syntactically awesome style sheets." It adds a layer of functionality on to your CSS script that makes it a far more verbose and functional approach to stylesheets. Click here for even more information. ② In this app, you've got a bunch of packages and dependencies that make for a great looking / functioning application. While Composer orchestrates and organizes PHP dependencies, Laravel Mix is organizing your Node tech. It's a layer of functionality positioned over the JS Webpack technology. You'll use npm run watch to keep track of any updates or changes to those technologies to ensure your app doesn't get hung up on an upgrade that it isn't prepared for. Here's what the Laravel docs say... iii) composer.json (back to top...) This is similar to Node in that you've got several "packages" that are needed in order for this puppy to run. While npm install uploads all of your Node dynamics, composer install uploads all of your PHP tech. 2) Basic Files (back to top...) i) npm run watch (back to top...) "npm run watch" is a needed piece of tech in order to update your vue.js files. Reason being is that "vue" is a framework. There's a difference between a library and a framework... That being the case, when you make changes to your vue.js files within Laravel, you're affecting more than just that one line of code. Rather, you're potentially affecting several files, hence the need for npm run watch ii) welcome.blade.php (back to top...) ① CSRF stands for "Cross-Site Request Forgery." It's an incredibly clever way of maintaining your site's security. Here's a great example from stackoverflow.com. Vue sometimes complains if this isn't in place. ② Bootstrap stuff ③ this is where your "vue.js" files are being displayed ④ this is the "app.js" file that's coming from your "js" directory. This is what's coordinating your Vue.js files iii) app.js (back to top...) ① Vue provides an ES module that is used by webpack. "Webpack" is a module bundler which is a tool that takes pieces of JavaScript and their dependencies and bundles them into a single file, usually for use in the browser. Refer to the graphic to the right to get an idea of how it works and what it does. Bottom line: In JavaScript, if you're still manually including each JavaScript file you depend on with a script tag... there's a better way! ES6 introduced the concept of modules: the ability (finally!) to isolate our JavaScript into small components that live in different files (like we do with classes in JavaScript). But, to get this to work on the web, we need some help. We need something that's able to read our imports and aggregate everything we need into a single JavaScript file. We need webpack! (taken from symfonycasts.com). ② this is a Vue Component. You're associating it with the "navbar" element in the DOM (Data Object Model). ③ this is coming from the Vue documentation... In other words, you have a new Vue instance (const app...) and with the "el" syntax you're saying you defining the element (el) that you want to mount your Vue instance on. BOOM! iv) Articles.vue (back to top...) Here's the first round of code that we built... ① These tags make complete sense when you consider what it looks like when you're writing straight Vue.js code. Here's a portion of the tutorial on Vue.js in 60 Minutes: import Vue from 'vue' // import Vue import App from './App' // import your main "App" component from Vue new Vue({ // new Vue instance el: '#app', // this is the element that we're attaching the Vue instance to. In this case, the name of the element is "app." template: '<App/>', // the <template> tag is actually an HTML element. See callout to the right... components: { App } // a list of all the components you're going to foward to your <template> tag. Technically, this is where you're "registering your components }) ② export default is part of the ES6 version of JavaScript. It's basically saying that you want to export everything you're getting ready to program. ③ data() is a property of a Vue instance that sets the properties of that Vue instance, and those properties can be accessed by and bound to the component. Here's an example that's coming from EE: <div id="myApp"> <h1>Hello {{ name }}</h1> </div> new Vue({ el : '#myApp', data : { name: 'Chris' } }); In the single instance example above, you'll see that the value of the data property is just an object (which has a single property called name). When you're building re-usable components, your data property needs to be a function that returns an object. This is so that each instance (copy) of your component has access to it's own copy of the data (otherwise changing a property value on one instance would change the value on all instances!) The syntax you've used above is just shorthand for the following: export default { data : function() { return { prop1 : "Some Value", prop2 : "Another Value", } }, As far as what you have after "return," here's a quick summary of objects and arrays as they're used in JavaScript: In Javascript you have Arrays and you have Objects. Generally speaking an Array is a collections of 'things', and an Object is a single 'thing' that contains related properties (for example a Customer object might have a FirstName property, and a LastName Property). An Array can contain a collection simple things (primitives), such as strings, numbers etc (the contents of an array don't have to be the same type!), but it can also contain a collection of Objects. An Object contains properties, which in turn can also be Arrays! Arrays use the square brackets and you access the elements of that array using the zero-based index: var myArray = ["Value1", "Value2", "Value3"]; console.log( myArray[0] ); // Value 1; Objects use the curly brackets and you access the properties using the period: var myObject = { FirstName : "Chris", LastName : "Stanyon" }; console.log( myObject.FirstName ); // Chris As I said, Arrays can contain Objects, and Object Properties can be Arrays! var customers = [ { FirstName : "Chris", LastName : "Stanyon", PhoneNumbers : [ "123456", "098876" ] }, { FirstName : "Bruce", LastName : "Gust", PhoneNumbers : [ "00000", "55555" ] }, ]; What we have here is an Array of Customer Objects. Each Customer has 3 Properties - FirstName, LastName and PhoneNumbers. PhoneNumbers is an Array. You can access the data like so: customers[0].FirstName; // FirstName property of the 1st customer customers[1].LastName; // LastName property of the 2nd customer customers[1].PhoneNumbers[0]; // 1st PhoneNumber of the 2nd customer This is coming from a Fitbit project that we worked on a while ago and you can see some more context by clicking here ④ "created" is a "Lifecycle Hook. Basically, it's a label that indicates in what order is a particular piece of code going to fire. Click on the link for more information and / or refer to the diagram to the right to see what kind of role it plays in the overall scheme of things. ⑤ pretty straight forward. This is your list of methods. In this case, we're grabbing the results from an api and retrieving them as JSON. The above code gives you what is coming from your api/artilces API which looks like this: {"data":[{"id":33,"title":"Test Title","body":"test body","created_at":"2019-11-10 02:21:19","updated_at":"2019-11-10 02:21:19"},{"id":31,"title":"Test Title","body":"test body","created_at":"2019-11-10 02:20:57","updated_at":"2019-11-10 02:20:57"},{"id":1,"title":"Ad magnam rerum eaque. Laborum est ipsa labore.","body":"Facilis illum vel qui odio laudantium et doloremque alias. Nisi eum ipsum quibusdam ut. Sed pariatur accusamus facilis similique quis iusto.","created_at":"2019-11-09 04:02:01","updated_at":"2019-11-09 04:02:01"},{"id":3,"title":"Dolores ut ut animi quia.","body":"Aliquid autem eum quidem perferendis deleniti corporis et magnam. Laborum et beatae aut doloremque nulla consequatur qui. Tempore sit ut culpa ut voluptatem quod repudiandae nam.","created_at":"2019-11-09 04:02:01","updated_at":"2019-11-09 04:02:01"},{"id":4,"title":"Updated Tite","body":"updated body","created_at":"2019-11-09 04:02:01","updated_at":"2019-11-10 02:39:31"}],"links":{"first":"http:\/\/larticles.site\/api\/articles?page=1","last":"http:\/\/larticles.site\/api\/articles?page=7","prev":null,"next":"http:\/\/larticles.site\/api\/articles?page=2"},"meta":{"current_page":1,"from":1,"last_page":7,"path":"http:\/\/larticles.site\/api\/articles","per_page":5,"to":5,"total":31}} 3) Cadillac Display (back to top...) Here's how we code this thing so it looks camera ready! ① assigning the data that we're getting back from our method to the articles[] array we're returning ② this is Vue.js code. We're getting ready to loop through the associative array that we've got with . The one thing that's a little unique is the key that Vue.js expects which is what I've got highlighted here: v-for="article in articles" v-bind:key="article.id" You see this explained in the Vue.js documentation: <div v-for="item in items" v-bind:key="item.id"> <!-- content --> </div> ③ card card-body mb-2 -> these are Bootstrap classes for "cards." mb-2 is another Bootstrap setting that stands for "margin body." This is what gives us a little extra space. ④ you're adjusting your fetchArticles a little bit by passing in a "page_url" variable. If that variable is present, you're going to be fetching those articles with the fetch functionality that coincide with that particular value. Otherwise, you're just grab what's coming from the "normal" api/articles dynamic. ⑤ vm stands for "view model." When you instantiate a "View" instance, you automatically have access to all the functionality contained within the "View" dynamic. "Pagination" is one of those things that is provided through that package. ⑥ this is the pagination code that you can get from Bootstrap ⑦ v-bind is what Vue.js uses to handle dynamically changed entities based on incoming data. 4) Delete Article (back to top...) We're going to start by adding a "delete" button on the card: <button @click="deleteArticle(article.id)" class="btn btn-danger">Delete Articles</button> Next, we'll add this function: deleteArticle(id) { if(confirm('Are you sure?')) { fetch(`api/article/${id}`, { notice the " ` " character. You may very well get another effort method: 'delete' }) .then(res => res.json()) .then(data => { alert('Article Removed') this.fetchArticles(); }) .catch(err => console.log(err)); } } 5) Add Article Form (back to top...) Here's your first piece: <input type="text" class="form-control" placeholder="title" v-model="article.title"> Take a look at what "v-model" is all about:

v-model -> You can use the v-model directive to create two-way data bindings on form input, textarea, and select elements. It automatically picks the correct way to update the element based on the input type. Although a bit magical, v-model is essentially syntax sugar for updating data on user input events, plus special care for some edge cases (from the Vue.js docs).

Here's your input for your body and your button: <div class="form-group"> <textarea class="form-control" placeholder="body" v-model="article.bodyu"></textarea> </div> <button type="submit" class="btn btn-light btn-block">Save</button> Now, here's your code. You're going to be using the same method for both the "add" and "update" functionality with some obvious differences depending on the "edit" value which is set to "false" by default. Here's your "addArticle" code:

addArticle() { if(this.edit === false) { //add fetch(`api/article`, { method: 'post', body: JSON.stringify(this.article), headers: { 'content-type': 'application/json' } }) .then(res => res.json()) .then(data => { this.article.title = ''; this.article.body = ''; alert('Article added'); this.fetchArticles(); }) .catch(err => console.log(err)); } else { //update } }

Now, we add the "edit" dynamic: First of all, here's your button: <button @click="editArticle(article)" class="btn btn-warning mb-2">Edit Article</button> ...and here's your code:

addArticle() { ❶ if(this.edit === false) { //add fetch(`api/article`, { method: 'post', body: JSON.stringify(this.article), headers: { 'content-type': 'application/json' } }) .then(res => res.json()) .then(data => { this.article.title = ''; this.article.body = ''; alert('Article updated'); this.fetchArticles(); }) .catch(err => console.log(err)); } else { //update ❷ fetch(`api/article`, { ❸ method: 'put', ❹ body: JSON.stringify(this.article), headers: { 'content-type': 'application/json' } }) ❺ .then(res => res.json()) .then(data => { this.article.title=''; this.article.body=''; alert('Article Updated'); this.fetchArticles(); }) .catch(err => console.log(err)); } }, editArticle(article) { this.edit = true; this.article.id = article.id; this.article.article_id = article.id; this.article.title = article.title; this.article.body = article.body; }

① first of all, it's worthwhile to revisit the fact that the "edit" value has been set to "false" by default. That was the edit: false piece in your "export" part of the code. ② fetch() is an "out of the box" piece of syntax that's designed to work with an API and provide a response that you can then configure however you want. Here's some material from the docs... const response = await fetch('http://example.com/movies.json'); const myJson = await response.json(); console.log(JSON.stringify(myJson)); You'll notice that the code above differs from what we wrote. This is "await" vs "promise. "await" is the way to go and you can read more about it here. The next two lines: .then(res => res.json()) .then(data => { The first "promise" returns your response which, in this case, you're formatting to JSON. The second promise gives you the chance to take that data and do something with it. Click here to watch a tutorial about it. ③ PUT requests are a JavaScript thing. Here's a good explanation: PUT requests will be used to make updates to existing resources. It’s important to note that PUT is used to replace the entire resource – it doesn’t do partial updates (I will show you how to do this with PATCH in the future). Return to the controllers/employees.js file and add the following code to the bottom...

...this is from JavaScript and Oracle

async function put(req, res, next) { try { let employee = getEmployeeFromRec(req); employee.employee_id = parseInt(req.params.id, 10); employee = await employees.update(employee); if (employee !== null) { res.status(200).json(employee); } else { res.status(404).end(); } } catch (err) { next(err); } } module.exports.put = put;

④ although I've documented this as two distinct bullet points, this is all one big, function... fetch(`api/article`, {method: 'put', body: JSON.stringify(this.article), headers: { 'content-type': 'application/json' } "body," in this case is going to be processed as the comprehensive "body" of info you're going to insert into the database. ⑤ we talked about this earlier in the context of "fetch()." These are the standard lines of code found in your typical "fetch..." .then(res => res.json()) .then(data => { this.article.title=''; this.article.body=''; alert('Article Updated'); this.fetchArticles(); }) And that's it!

 XI) NOMAS Finished Project

A) Incorporating Security (back to top...) The challenge here is to incorporate all of the "Register" and "Login" links etc and superimpose all of that over the Bootstrap template that you currently have in place. 1) Setup Database (back to top...) First of all, you're running Laravel 6, so there's some nuances that you need to be aware of. You see that when you're setting up your tables.

• begin by setting up your database and adjusting your ".env" file
• alter your AppServiceProvider.php file in your "app/Providers" directory with this:

public function boot() { // Schema::defaultStringLength(191); // this prevents an error to get thrown that says a particlar key is too long (click here for more info) } 2) Migrations and Page Creation (php artisan make:auth) (back to top...) Again, there are things about version 6 that differ from some of the tutorials that assume you're using version 5. To do all your table migrations and set up your pages, you have to do the following:

composer require laravel/ui php artisan ui vue --auth php artisan migrate

This works after you've set up your database. Also, to determine the version of Laravel you're using, you'll run this command:

Bruce@WINDOWS-2SH5T3I MINGW64 /c/wamp64/www/new_nomas $ php artisan --version Laravel Framework 6.1.0

At that point, you've got everything you need to login, register, retrieve a forgotten password...it's awesome! 3) Understanding and Setting Up the Login Screen (back to top...) When you run the above commands, you're doing more than what might appear to be the case on the surface. One example of that is the way in which the login process and routing is now firing automatically in ways that aren't necessarily obvious. For example, those pages that can only be accessed by an authenticated user are protected by the incorporation of middleware that you reference in your Controller. Take your AdminController.php page. You'll most likely have something like this: public function __construct() { $this->middleware('checkRole:admin '); } That Middleware has to be registered. To do that, you'll add 'checkRole' => \App\Http\Middleware\CheckRole::class, to your "Kernel.php" page. That is now firing with every request that's made to that page. Notice, it's checking the role of the person who's supposedly logged in and already authenticated. To trace the routing and the nuts and bolts of what's actually happening, you have to go to the Middleware itself. With "checkRole," you'll go to the "CheckRole.php" page to see what's happening. But here's something to be aware of: When all of this is orginally set up, you automatically have routes set up for "login" and all of the other authentication pages you'll need. On the "web.php," you'll see this: Auth::routes();. That's referring to a collection of routes on the "Router.php" located in the "vendor\laravel\framework\src\Illuminate\Routing" directory. Here are those routes:

public function auth(array $options = []) { // Authentication Routes... $this->get('login', 'Auth\LoginController@showLoginForm')->name('login'); $this->post('login', 'Auth\LoginController@login'); $this->post('logout', 'Auth\LoginController@logout')->name('logout'); // Registration Routes... if ($options['register'] ?? true) { $this->get('register', 'Auth\RegisterController@showRegistrationForm')->name('register'); $this->post('register', 'Auth\RegisterController@register'); } // Password Reset Routes... if ($options['reset'] ?? true) { $this->resetPassword(); } // Email Verification Routes... if ($options['verify'] ?? false) { $this->emailVerification(); } }

When you try to pop the hood on "Auth/LoginController@showLoginForm," you might find yourself feeling a little exasperated because you won't see a function called, "showLoginForm." But you will find it on the "AuthenticateUsers.php" page which is referenced at the top: use Illuminate\Foundation\Auth\AuthenticatesUsers; On that page, you'll see this: public function showLoginForm() { return view('auth.login'); } B) Positioning of Login | Register Links (back to top...) You needed to make a couple of changes in your template. Here's what happened... 1) welcome.blade.php

<div class="top-area"> <div class="container"> <div class="row"> <div class="col-md-12"> <div class="row"> <div class="col-xs-6 training_schedule"> <b>NOMAS^® Training Schedule</b> </div> <div class="col-xs-6 training_register"> <!-- start login links--> @if(Auth::check()) <a href="{{ route('dashboard') }}">Dashboard</a> <form method="Post" id="logout-form" action="{{ route('logout') }}">@csrf</form> <a href="#" style="font-weight:bold;" onclick="document.getElementById('logout-form').submit();">Logout</a> @else <a href="#" style="color:#fff; font-weight:bold;" href="{{ route('login') }}">Login</a> |  <a href="#" style="color:#fff; font-weight:bold;" href="{{ route('register') }}">Register</a> @endif <!-- end login links --> </div> </div> </div> </div> </div> </div>

The highlighted sections are where we added a row within a row to accommodate the "Login | Register" links to line up on the top right hand section of the site. 2) style.css (back to top...) To keep the new top section looking good, some changes had to be made in the "style.css" file. It's a hefty piece of code. The parts that are relevant are the classes of "training_register" and "training_schedule." Here's an example of what you see for the "@media (max-width:367px) {" section on line #2121. .training_register { text-align:right; font-size:6pt; } .training_schedule { font-size:6pt; } While the "auth" piece puts your basic login infrastructure in place, you will need additional functionality for your Admin Suite. First thing you're going to do is create your "roles" table...

Bruce@WINDOWS-2SH5T3I MINGW64 /c/wamp64/www/new_nomas $ php artisan make:model Role -m Model created successfully. Created Migration: 2019_12_28_013531_create_roles_table

C) User Login and Administrator (back to top...) A lot of the infrastructure you need to login is already in place by default thanks to the "auth" command. Still, there were some additional concepts and elements that had to be added in order to get this puppy to fire correctly. Regular User vs Administrator What's going to determine whether or not a user is a basic customer or an administrator is the value of "1" in the admin column in the user's table. That column had to be added. The "Login | Register" links at the top were changed so they now displayed, "Admin Page | Dashboard | Logout" if a user was logged in AND had administrative privileges. Here's the code that made all that happen:

<!-- start login links--> ❶ @if(Auth::check()) ❷ @if(Auth::user()->admin==1) <a href="{{ route('adminDashboard') }}" style="color:#fff; font-weight:bold;">Admin Page</a> | <a href="{{ route('userDashboard') }}" style="color:#fff; font-weight:bold;">Dashboard</a> | <form method="Post" id="logout-form" action="{{ route('logout') }}" style="display:inline;">@csrf</form> <a href="#" style="font-weight:bold; color:#fff;" onclick="document.getElementById('logout-form').submit();">Logout</a> @else <a href="{{ route('userDashboard') }}" style="color:#fff; font-weight:bold;">Dashboard</a> | <form method="Post" id="logout-form" action="{{ route('logout') }}" style="display:inline;">@csrf</form> <a href="#" style="font-weight:bold; color:#fff;" onclick="document.getElementById('logout-form').submit();">Logout</a> @endif @endif ❸ @if(Auth::guest()) <a href="/login" style="color:#fff; font-weight:bold;" >Login</a> |  <a href="#" style="color:#fff; font-weight:bold;" href="{{ route('register') }}">Register</a> @endif <!-- end login links -->

① "Auth" is an object instantiated when a user logs in. You have access to several properties / values within that object. "check" gives you the ability to see if a user has logged in. ② the closest I came to a nested IF statement. If a user is logged in, the next step is to see if they've got admin permissions ③ if the user is merely a guest as opposed to someone who has logged in, this is the verbiage they'll see displayed. By the way, a great video to watch that details permissions in the context of various users and tasks is available here. D) Pages (back to top...) 1) Pages Table (back to top...) To create an interface that allows you to create and update pages, the first thing you'll need to do is create the "pages" table. There's more than one way to skin a cat, but here's a good method that kills a couple of birds with one stone. Here's a command that creates the table as well as its corresponding model... php artisan make:model Page -m Running that code gives you the basic table as well as the Model which is stored in the "app" directory. After the basic table is created, you're going to want to put in some new columns. To do that, go to the "database/migrations" directory and edit the code that represents the schema of the newly formed "pages" table.
Warning: Undefined variable $coede_frame in /home/cgob4051moa0/public_html/adm/laravel/index.php on line 4560
public function up() { Schema::create('pages', function (Blueprint $table) { $table->bigIncrements('id'); $table->string('title'); $table->binary('body'); $table->timestamps(); }); }