Forem: Alhassan Kamil

Publishing a Course Isn't That Difficult Like You Think, AND It Pays

Alhassan Kamil — Wed, 27 Jul 2022 17:58:46 +0000

As a programmer, you may think you're too much into writing code and getting systems built, so you have no time for writing courses. You're not alone. I thought the same until about a year and a few months ago when everything changed, for the better.

I was always the consumer of courses but never a producer. Oh, I even thought I wasn't good enough to publish courses. What I failed to understand is that you learn more by teaching than you do by learning.

I Failed In an Instant, Then I Got Up 🚀

Fast forward in 2019-2020, I got to know about raywenderlich.com at a time they were looking for technical editors for Flutter. I became interested and applied. Unfortunately, I couldn't qualify since my social profiles were not looking great and I didn't have enough content to prove my worth too.

Then came 2021. I had an email from the team at raywenderlich.com again that it's been a year since I was rejected and I may try again.

At first, I said no, thinking it was one of the spam emails I constantly received. But then, Annette replied that I should let her know if I ever change my mind. That was when I remembered that I applied for this the past year. And that's when my story began!

The Beginning of My Adventure

I went through a tryout and finally got a chance to tech-edit an article. It was overwhelming at first, but I grew to like it for the fact that I learned more than I could ever do if I had to read a tutorial.

My second article came like a breeze and I was already loving everything about tech-editing, especially at raywenderlich. It even made me get more interested in writing. So I started my own blog and began my writing process.

Within a few months, I had an email from Educative.io asking me to publish a course on AlpineJs. I gladly did and here's the next part of my story.

Publishing My First Course

Publishing my first course wasn't that easy, but it wasn't too difficult either. It took months for it to get through various stages. It got to a time I almost became fed up waiting but I eventually understood what it takes to publish a great course.

Finally, we published the course in May 2022. Honestly, I've benefited from the course more than I've ever done with any of the projects I created for clients. What's more, I'm still getting paid monthly for promoting the course, unlike the one-time payment I get from developing software for clients.

The course is titled Mastering AlpineJS in a Day or Less, if you care to know. And, it was my first paid course so you know how proud I became after it was published.

Going Forward...

After I submitted my work for editing on Educative.io, my interest in authoring technical content grew exponentially. So I asked my team lead at raywenderlich.com to give me a chance to write an article. He did, and I published my first article: Building Dart APIs With Google Cloud Run.

Ever since, I've been an active part of the raywenderlich.com Flutter team and an author at Educative.io and I'm loving it. I've never looked back and I like the fact that I get paid for learning and doing what I love so much.

I hope this article gingers you up to start writing, not only for the pay but for the learning benefits too. Let me know your story in the comments. What are your experiences?

Creating Your First Blog With TALL - Part Eight

Alhassan Kamil — Fri, 30 Apr 2021 10:04:00 +0000

This episode is the eighth in the Creating Your First Blog With TALL series. You'll finish up with the admin area by implementing the edit page for a post. You'll also ensure that only admins are able to access the admin dashboard by using Laravel middleware in this episode.

At the end of the episode, you should be able to:

update database records using Eloquent.
restrict access to certain parts of your Laravel web app using middleware.

It's important to note that the project up to this phase is available here on GitHub. So if you're late to the party, you can clone it and continue with us. :)

Creating the Edit Post Component

In the previous episode, you made sure admin users were able to create, delete and publish/unpublish posts. You're going to add another important feature in this tutorial: allow the admin to edit a post after it's been created.

This feature is particularly useful if you ever need to correct an error after you publish a post. Or, if your blog is in the technology landscape and you need to update posts in relation to changes in your technology stack. So it's necessary that a blog has this feature.

This component is almost the same as the NewPost component we created in the last episode(they both have the same form fields). As a result, we'd be reusing the view file for the NewPost component with a few modifications.

Create the EditPost Livewire component by running the Artisan command:

php artisan make:livewire Dashboard.EditPost --inline

You have made it an inline component because the view for the NewPost component will be reused.

Open the component class and replace its contents with this:

<?php //tall-blog/app/Http/Livewire/Dashboard/EditPost.php

namespace App\Http\Livewire\Dashboard;

use App\Models\Post;
use Livewire\Component;

class EditPost extends Component
{
    public $post;
    public $isEdit = true;

    protected $rules = [
        'post.title' => 'required|string',
        'post.category' => 'required',
        'post.body' => 'required|string|min:500',
        'post.excerpt' => 'required|min:100:max:250',
        'post.is_published' => 'boolean',
    ];

    public function mount($id)
    {
        $this->post = Post::find($id);
    }

    public function render()
    {
        return view('livewire.dashboard.new-post');
    }

    public function save()
    {
        $this->validate();
        $this->post->save();
        session()->flash("message", "Post update successful");
    }
}

What you're basically doing here is fetching the post you want to edit from the database. You did this using the mount method. $post refers to this post and you're making it available in the view, as happens with every supported public variable in a Livewire component. Note that all properties of the $post variable will now equally be available in the view. This makes it easy for you to take advantage of the model binding previously used in the new post view.

You use $isEdit to track the component you're working with in the view. Remember you're reusing the new post component's view. So $isEdit is there to check whether you're dealing with the NewPost component class or the EditPost component class.

The $rules property is similar to the one used in the NewPost component, albeit without a few fields. These fields are not included because they don't need to be updated when a post is updated.

Then you come to the save method. This validates the fields you want to update against the rules you defined in the $rules property. It then saves everything and flashes a success message to the session, notifying the view that the update was successful.

You'll now have to make three important changes to the new post view at resources/views/livewire/dashboard/new-post.blade.php.

First, you'll have to display the success message from the session after a post is updated. Secondly, you need to display "Edit post" as title if you're editing a post or "New post" if you're creating a new one. Lastly, you'll have to modify the Submit button's text to either show "Submit" if the post is being edited or "Next" if you're creating a new post.

Replace the New post heading with the following code snippet just below the opening div at the top of resources/views/livewire/dashboard/new-post.blade.php:

<?php //tall-blog/resources/views/livewire/dashboard/new-post-blade.php
...
<h1 class="mb-3 text-xl font-semibold text-gray-600">
    {{ isset($isEdit) ? "Edit post": "New post" }}
</h1>
@if (session()->has('message'))
    <div class="flex flex-row justify-between p-2 mb-4 text-green-900 
         bg-green-600 bg-opacity-25 rounded-md">
        {{ session('message') }}
    </div>
@endif
...

This displays the success message as soon as it's flashed to the session.

Next, update the text of the Submit button to the following:

<?php //tall-blog/resources/views/livewire/dashboard/new-post-blade.php
...
{{ __(isset($isEdit) && $isEdit ? "Submit": "Next") }}
...

This shows "Submit" if you're editing a post, else "Next" is shown. This is so because for a new post, the button submits the form and then redirects to the upload featured image page.

Save all files to continue.

Congratulations! You're now done with all things concerning components for your blog.

Your next task is to configure the route for the edit post component. Remember the route currently returns the dashboard view. Do replace the existing route with the following code:

<?php //tall-blog/routes/web.php
...
Route::get('post/edit/{id}', EditPost::class)->name('edit-post');
...

Make sure you include EditPost and all the other files at the top of the web.php route file. Now start your database server. Don't forget to start the built-in PHP server too. Point your browser to http://127.0.0.1:8000, login and click any Edit post button to see the edit page in action:

Changing any field and submitting the form shows the update success message:

Working With Middleware

As at now, every user that registers with your blog can login and perform any tasks you the owner can perform. This include creating new posts, deleting existing posts, publishing or unpublishing posts and editing existing posts. These actions are very dangerous for any user to do without your knowledge. You'd want any user registered with your blog to be prohibited from performing these tasks. Laravel allows you to do just that easily using middleware.

Laravel middleware provides a mechanism for you to scrutinize and filter incoming HTTP requests. This has many advantages. First, it allows you to control incoming requests that can compromise your website. It also allows you to restrict and/or give access to some parts of your website to specific user groups.

Laravel includes a lot of middleware in the framework. This ranges from authentication, CSRF protection, CORS to a handful of other middleware used by the framework behind the scenes.

You create a middleware with the make:middleware Artisan command like so:

php artisan make:middleware MiddlewareName

This creates a MiddlewareName middleware in your app/Http/Middleware directory.

Creating the Admin Middleware

In this section, you're going to create an AdminMiddleware. The admin middleware will be used to restrict access to the admin dashboard for only admin users. In our case, there's going to be only one admin user in the system. Any other user who logs in to the system will be redirected to the blog homepage.

Create the middleware by running the Artisan command:

php artisan make:middleware AdminMiddleware

Now open the file. Make sure it is equal to this code:

<?php //tall-blog/app/Http/Middleware/AdminMiddleware.php
namespace App\Http\Middleware;

use Closure;
use Illuminate\Http\Request;

class AdminMiddleware
{
   /**
    * Handle an incoming request.
    *
    * @param \Illuminate\Http\Request $request
    * @param \Closure $next
    * @return mixed
    */
   public function handle(Request $request, Closure $next)
   {
       if ($request->user()->user_type !== 'admin') {
           return redirect()->to(route('home'));
       }
       return $next($request);
   }
}

Every Laravel middleware has the handle method which handles the incoming request. Within the method, you can perform any tasks before or after the request is handled by the application.

Your AdminMiddleware checks if the user performing the request is an administrator. If not so, they're redirected to the homepage. Otherwise, the request is passed on to the application to be handled using the $next closure.

Registering the AdminMiddleware

For the admin middleware to work, you have to register it. There are two ways to doing this. First, you register global middleware (middleware that runs for all requests in the application) by adding it to the $middleware list property in your app's app/Http/Kernel.php file. For middleware that should only run during some specific requests or on some routes, you register it by adding it to the $routeMiddleware list property.

Since the admin middleware is run only on requests to the admin dashboard, you'll use the second approach. Add the AdminMiddleware class to the $routeMiddleware list property in the app/Http/Kernel.php file with the key 'admin':

    /**
     * The application's route middleware.
     *
     * These middleware may be assigned to groups or used individually.
     *
     * @var array
     */
    protected $routeMiddleware = [
        'admin' => \App\Http\Middleware\AdminMiddleware::class,
        'auth' => \App\Http\Middleware\Authenticate::class,
        'auth.basic' => \Illuminate\Auth\Middleware\AuthenticateWithBasicAuth::class,
        'cache.headers' => \Illuminate\Http\Middleware\SetCacheHeaders::class,
        'can' => \Illuminate\Auth\Middleware\Authorize::class,
        'guest' => \App\Http\Middleware\RedirectIfAuthenticated::class,
        'password.confirm' => \Illuminate\Auth\Middleware\RequirePassword::class,
        'signed' => \Illuminate\Routing\Middleware\ValidateSignature::class,
        'throttle' => \Illuminate\Routing\Middleware\ThrottleRequests::class,
        'verified' => \Illuminate\Auth\Middleware\EnsureEmailIsVerified::class,
    ];

Once this is done, your next task is to assign the middleware to the dashboard route group. Open the routes/web.php file and add it to the existing auth:sanctum middleware:

'middleware' => ['auth:sanctum', 'admin']

Make sure your routes/web.php route file looks exactly like this now:

<?php

use App\Http\Livewire\CategoryPosts;
use App\Http\Livewire\Dashboard\FeaturedImageUpload;
use App\Http\Livewire\Dashboard\NewPost;
use App\Http\Livewire\Detail;
use App\Http\Livewire\Dashboard\EditPost;
use App\Http\Livewire\ShowPosts;
use Illuminate\Support\Facades\Route;

/*
|--------------------------------------------------------------------------
| Web Routes
|--------------------------------------------------------------------------
|
| Here is where you can register web routes for your application. These
| routes are loaded by the RouteServiceProvider within a group which
| contains the "web" middleware group. Now create something great!
|
*/

Route::get('/', ShowPosts::class)->name('home');

Route::get('categories/{category}', CategoryPosts::class)->name('category');

Route::group(['prefix' => 'dashboard', 
   'middleware' => ['auth:sanctum', 'admin']], function () {
    Route::get('/', function () {
        return view('dashboard');
    })->name('dashboard');

    Route::get('post/add', NewPost::class)->name('new-post');

    Route::get('post/upload/{id}', FeaturedImageUpload::class)->name('upload-featured-image');

    Route::get('post/edit/{id}', EditPost::class)->name('edit-post');
});

Route::get('{slug}', Detail::class)->name('post-detail');

Save all files. Now refresh your browser and you should be redirected to the homepage:

Updating the Users Table

Though in the previous section you were logged in, you were still redirected to the homepage. This is going to be the fate of any new user who registers for your blog at the moment. This includes you because the website doesn't yet recognize you as an admin.

The AdminMiddleware only allows users whose user_type is 'admin'. Currently, however, this column isn't in the users table. Therefore, you're redirected to the homepage since the constraint isn't met.

To add the user_type column to the users table and make your self an admin, create an add_user_type_column migration using the Artisan command:

php artisan make:migration add_user_type_column --table=users

Open the migration file and make sure it contains this code:

<?php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

class AddUserTypeColumn extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::table('users', function (Blueprint $table) {
            $table->enum('user_type', ['admin', 'normal'])->default('normal');
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::table('users', function (Blueprint $table) {
            $table->dropColumn('user_type');
        });
    }
}

This adds the user_type column to the users table and makes 'normal' as the default user type. This means anyone registering for the blog will be a normal person. Also, notice how the column is made an enum. This ensures only the two values are allowed.

Now run the migration to migrate the changes:

php artisan migrate

Inspect your database and you should be able to see the column added. You must then change the user type for the row containing your account details to 'admin' instead of the default 'normal' type.

You should save all files and click the Login menu link to login. Because you're already logged in, you'll be sent directly to the dashboard:

Congratulations once again! You have successfully finished developing your blog with the TALL stack. I believe you've learnt a lot in the process. You should clap for yourself for coming this far!

This completes today's episode of this series. The next episode will be about optimizing your Laravel application before deployment. I'll teach you how to make your app faster, efficient and secure before deploying to your server.

See you for that session soon. Bye!

Creating Your First Blog With TALL - Part Seven

Alhassan Kamil — Fri, 30 Apr 2021 08:19:00 +0000

Hey! Just so you know if today is your first time being here, this is a tutorial series and this one is the seventh episode of the tutorial series

In the previous episode, you learnt how to create a responsive navigation bar for the blog using Tailwind CSS and Alpinejs. You also learnt how to layout a post detail page using utility classes from Tailwind CSS. As is always the case, this episode builds on that by teaching you how to create posts using Laravel Livewire.

At the end of this episode, you should be able to:

delete, publish and unpublish posts using Livewire actions.
add new posts to the database using Eloquent.
style forms with Tailwind CSS.
use Laravel Livewire model binding to bind properties from Livewire components to forms in the view files.
validate forms using Livewire.
upload files using Laravel Livewire.

Note: I've noticed that the slug wasn't added to the Post model and the create posts migration. If you didn't also notice and correct it, kindly add slug to the $fillable array in app/Models/Post.php and modify the create posts migration accordingly(make the featured_imagecolumn too nullable). Then run php artisan migrate:refresh to rollback and rerun the migrations.

Note: The above truncates all your data, including users data. We're taking this approach because updating only the slug column means we have to provide a slug for all posts. We also want to tidy up our posts table of the auto-generated data.

However, you'd need to recreate your account to continue with the tutorial.

First things first! Remember the view for the dashboard page was resources/views/dashboard.blade.php, and that was what you returned in the route for the dashboard page. Remember also that the default Jetstream welcome.blade.php component view was inserted into this view, making the default Jetstream dashboard display the welcome page.

Locate and delete this snippet from the resources/views/dashboard.blade.php to remove the welcome component:

<x-jet-welcome />

You're going to display posts you've already added in the dashboard, that's why you have to delete the welcome page.

Now you could just display the posts like how you did in the homepage but this is an admin area, so you wouldn't want to clutter the dashboard page. What will be more appropriate is to display minimal details of the posts in a table. This way, you can even add, edit and delete buttons to take actions on each post. This is the approach we're going to take.

Updating the web.php Routes File

For us to be able to preview the pages we're going to create in the next sections, the routes/web.php file needs to be updated. Please make sure its contents match the route definitions below:

use App\Http\Livewire\CategoryPosts;
// use App\Http\Livewire\Dashboard\FeaturedImageUpload;
// use App\Http\Livewire\Dashboard\NewPost;
use App\Http\Livewire\Detail;
use App\Http\Livewire\ShowPosts;
use Illuminate\Support\Facades\Route;

/*
|--------------------------------------------------------------------------
| Web Routes
|--------------------------------------------------------------------------
|
| Here is where you can register web routes for your application. These
| routes are loaded by the RouteServiceProvider within a group which
| contains the "web" middleware group. Now create something great!
|
*/

Route::get('/', ShowPosts::class)->name('home');

Route::get('categories/{category}', CategoryPosts::class)->name('category');

Route::group(['prefix' => 'dashboard', 'middleware' => 'auth:sanctum'], function () {
    Route::get('/', function () {
        return view('dashboard');
    })->name('dashboard');

    // Route::get('post/add', NewPost::class)->name('new-post');

    // Route::get('post/upload/{id}', 
        // FeaturedImageUpload::class
    // )->name('upload-featured-image');

    Route::get('post/edit/{id}', function ($id) {
        return view('dashboard');
    })->name('edit-post');
});

Route::get('{slug}', Detail::class)->name('post-detail');

You've commented the new post and featured image upload routes for now since these components are not yet available. After completely working on a component, you'll have to uncomment it here to make the route work.

Displaying Posts in the Dashboard

Create a new Posts Livewire component to display posts in the dashboard page:

php artisan make:livewire Posts

Open the file and make sure it is equal to this:

use App\Models\Post;
use Livewire\Component;
use Livewire\WithPagination;

class Posts extends Component
{
    use WithPagination;

    public function render()
    {
        $posts = Post::paginate(10);
        return view('livewire.dashboard.posts', 
                ['posts' => $posts]
            );
    }
}

You're using the WithPagination Livewire trait in this component. This trait makes paginating data using Livewire a breeze. You didn't make $posts a public variable because Livewire doesn't support using types other than the Stringable, Collection, DateTime, Model, EloquentCollection PHP types and the JavaScript data types this way(the paginate method returns a LengthAwarePaginator, not a collection of models).

Change the contents of the corresponding view to the following:

<div class="m-4">
    <div class="flex flex-row justify-between">
        <h2 class="text-xl font-bold text-gray-600">Posts</h2>
        <a href="{{ route('new-post') }}" class="px-2 py-1 text-white bg-green-700 rounded">New</a>
    </div>
    <div class="p-3">
        <!-- Session checks -->
        @if (session()->has('message'))
            <!-- Show message -->
            <div class="p-2 text-green-900 bg-green-600 bg-opacity-25 rounded-md">{{ session('message') }}</div>
        @endif
        <table class="table w-full">
            <thead class="text-sm text-gray-600 border-b border-gray-200">
                <th>Category</th>
                <th>Title</th>
                <th>Status</th>
                <th>Actions</th>
            </thead>
            <tbody class="text-sm text-gray-600">
                @foreach ($posts as $post)
                <tr class="table-row px-2 border-b border-gray-200 hover:bg-gray-100">
                    <td class="py-4">{{ $post->category }}</td>
                    <td>
                        {{ ucwords($post->title) }}
                    </td>
                    <td class="text-center">
                        {{ $post->is_published ? "Published" : "Pending" }}
                    </td>
                    <td class="text-center">
                        <button class="p-1 text-xs text-gray-100 bg-red-600 rounded-sm"
                        wire:click="delete({{ $post->id }})">
                            Delete
                        </button>
                        <button class="p-1 text-xs text-gray-100 bg-yellow-700 rounded-sm" wire:click="publish({{ $post->id }})">
                            {{ !$post->is_published ? "Publish" : "Unpublish" }}
                        </button>
                        <a href="{{ route('edit-post', $post->id) }}"
                            class="bg-blue-600 px-2 py-1.5 text-xs rounded text-white">Edit</a>
                    </td>
                </tr>
                @endforeach
            </tbody>
        </table>
        <div class="my-3">
            {{ $posts->links() }}
        </div>
    </div>
</div>

The view of a Livewire component must be laid out in a single top-level element, that's why we put everything in the div element. We've added a heading and a button linking to the page we'd use for creating new posts.

Remember Laravel helpers are also available in the views, so you're using the Session::has helper here to check for and display a message (which is from a session) when a post is deleted or published. Also, note the use of the @if @endif conditional block. This ensures the message is only displayed if there's a session that has the message variable.

Ignoring HTML, the next block iterates through the $posts and displays each post in a table row (tr). We have decided to display only a few columns from the posts table to make the table less cluttered.

Lastly from the loop, the Action column has three buttons: Delete for deleting this post, Publish/Unpublish for publishing/unpublishing this post, and Edit for editing the post.

While Edit is ordinarily a link to the edit post page, Delete and Publish/Unpublish bind the delete and publish methods in the Posts component to their wire:click event directives. The wire:click directive attaches the given method to the click event of the button element.

The last snippet is the $posts->links(). This adds the pagination links and is the same way a traditional Laravel app will display pagination. In other words, the difference between the syntax of a Livewire pagination and a traditional Laravel pagination is the use of the WithPagination trait. However, while pagination with Livewire doesn't refresh the whole page, Laravel's does and this is one advantage of using Livewire pagination.

Add the delete and publish methods to complete the Posts component:

public function delete(int $id)
{
    $post = Post::find($id);
    unlink(storage_path("app/public/posts/".$post->featured_image));
    $post->delete();
    session()->flash("message", "Post has been deleted");
}

public function publish(int $id)
{
    $post = Post::find($id);
    $status = $post->is_published ? "unpublished": "published";
    $post->is_published = !$post->is_published;
    $post->published_date = now();
    $post->save();
    session()->flash("message", "Post $status successfully");
}

The delete method first finds the post from the database using the post ID passed to it from the view. It then deletes the post's featured image from the storage folder using the storage_path helper to locate the file and the PHP unlink function for actually deleting the file. Lastly, we delete the post and flash a success method to the session.

Similarly, in the publish method you retrieve the post using its ID, set the status variable that specifies which word to use between 'published' and 'unpublished' in the success message, toggle the is_published column of the post, set the published_date column to the current date and then save the post back to the database. Finally, you flash the success message to the session for display in the view.

Save, start your servers and open your browser. Logging in to the dashboard should now show you posts available:

Adding New Posts

Your next task is to allow the administrator to create new posts when they're logged in. The new post route was added to make this possible. You even added a button that'll send you to the page where you can add a new post at the top of the posts table in the dashboard page. Though, as at now clicking this button sends you to the correct page, the page doesn't have this functionality. It currently returns the dashboard page.

Create a NewPost Livewire component to handle adding a new post:

php artisan make:livewire Dashboard.NewPost

Now, make sure the NewPost component contains the following:

<?php

namespace App\Http\Livewire\Dashboard;

use App\Models\Post;
use Illuminate\Support\Facades\Auth;
use Livewire\Component;

class NewPost extends Component
{
    public $post;

    protected $rules = [
        'post.title' => 'required|string',
        'post.category' => 'required',
        'post.body' => 'required|string|min:500',
        'post.excerpt' => 'required|min:100:max:250',
        'post.is_published' => 'boolean'
    ];

    protected $messages = [
        'required' => 'This field is required',
        'min' => 'Value must be more than :min chars',
        'max' => 'Maximum value is 250 chars'
    ];

    public function render()
    {
        return view('livewire.dashboard.new-post');
    }

    public function save()
    {
        $this->validate();

        $post = Post::create([
            'title' => $this->post['title'],
            'excerpt' => $this->post['excerpt'],
            'category' => $this->post['category'],
            'body' => $this->post['body'],
            'published_date' => now(),
            'user_id' => Auth()->user()->id,
            'is_published' => $this->post['is_published']
        ]);

        $id = $post->save();
        return redirect()->to(route('upload-featured-image', ['id' => $id]));
    }
}

Pretty many things are going on here. We have the $post member variable which holds all fields of a blog post. $rules define what validation rules should be applied to each field. You see that each rule has the post.{field} format as its key with the constraints that should be applied to it being the value. Occasionally, you'd only have the field as the key when you're dealing with a small and/or disjointed number of fields.

$messages show the provided messages for each constraint instead of the default Laravel validation error messages.

And finally, we have the save method that validates the form data against the $rules we specified earlier. When validation passes, you create a new post using the create method, save the post and redirect to the featured image upload page with the post id.

You'll now have to create the form in the resources/views/livewire/dashboard/new-post.blade.php view. Enter this code in that view to do so:

<div class="p-4 mx-auto mt-3 bg-gray-100 md:p-8 md:w-4/5 md:mt-0">
    <h1 class="mb-3 text-xl font-semibold text-gray-600">New post</h1>
    <form wire:submit.prevent="save">
        <div class="overflow-hidden bg-white rounded-md shadow">
            <div class="px-4 py-3 space-y-8 sm:p-6">
                <div class="grid grid-cols-6 gap-6">
                    <div class="col-span-6 sm:col-span-3">
                        <x-jet-label for="title">
                            {{ __("Post title") }}
                        </x-jet-label>
                        <x-jet-input class="w-full" type="text" 
                           wire:model="post.title" placeholder="Post title" />
                        <x-jet-input-error for="post.title" />
                    </div>

                    <div class="col-span-6 sm:col-span-3">
                        <x-jet-label>
                            {{ __("Excerpt") }}
                        </x-jet-label>
                        <x-jet-input type="text" class="w-full" wire:model="post.excerpt" 
                           placeholder="Excerpt" />
                        <x-jet-input-error for="post.excerpt" />
                    </div>
                </div>
                <div class="grid grid-cols-6 gap-6">
                    <div class="col-span-6 sm:col-span-3">
                        <x-jet-label for="category" 
                            class="block text-sm font-medium text-gray-700">
                            {{ __("Category") }}
                        </x-jet-label>
                        <x-jet-input id="category" wire:model="post.category" type="text"
                            placeholder="Category" class="w-full" />
                        <x-jet-input-error for="post.category" />
                    </div>
                    <div class="col-span-6 mt-4 sm:col-span-1">
                        <x-jet-label class="text-sm font-medium text-gray-700">
                            <x-jet-input wire:model="post.is_published" type="checkbox" 
                              class="form-checkbox" />
                            {{ __("Publish") }}
                        </x-jet-label>
                        <x-jet-input-error for="post.is_published" />
                    </div>
                </div>
                <div class="flex flex-col">
                    <x-jet-label for="body">
                        {{ __("Body") }}
                    </x-jet-label>
                    <textarea id="body" rows="4" wire:model="post.body" 
                       class="border-gray-300 rounded-sm form-textarea">
                    </textarea>
                    <x-jet-input-error for="post.body" />
                </div>
            </div>
            <div class="px-4 py-3 text-right bg-gray-50 sm:px-6">
                <x-jet-button class="inline-flex justify-center">
                    {{ __("Next") }}
                </x-jet-button>
            </div>
        </div>
    </form>
</div>

From this, wire:submit.prevent="save" ensures that when the form is submitted, the save method is called. Of course, this is the method that saves the post into the database. The other thing worth mentioning is that the .prevent event modifier prevents refreshing the browser(which is the default behavior when you submit a form). Thus, it's equivalent to the event.preventDefault() JavaScript modifier.

You're making use of the Jetstream components for the form's elements here. The <x-jet-label ...> elements represent the Jetstream label component which we make use here. The <x-jet-input ...> is an input component while the nearby <x-jet-input-error ...> displays errors associated with that input field. We also have the <x-jet-button ...> component which submits the form. All these components can be found in the resources/views/vendor/jetstream/components folder at the root of the project(we talked about this in the earlier episodes).

We decided to use the ready-made Jetstream components because apart from that being easier, it reduces the time we'd have spent crafting and designing the form ourselves. This also helps us to follow the DRY principles.

Save all files and try to click the New post button to see the form in action. Try to submit without providing the required fields, or by providing invalid data and you should see errors displayed next to each invalid field.

This is how the form looks like:

The last thing left for us to work on is the featured image upload page. This is necessary because when you submit the form with valid data, it sends you to the next page for the upload. This will be covered in the next section.

Uploading Files

Just like many other things, Livewire supports file uploads out of the box. It handles file uploads like you would with other form input fields. The only different thing you need to add to take advantage of this feature is to add the WithFileUploads trait to your Livewire component.

Create a new FeaturedImageUpload component in the Dashboard namespace:

php artisan make:livewire Dashboard.FeaturedImageUpload

Open the component class and modify it to equal the following:

<?php

namespace App\Http\Livewire\Dashboard;

use App\Models\Post;
use Livewire\Component;
use Livewire\WithFileUploads;
use Illuminate\Support\Str;

class FeaturedImageUpload extends Component
{
    use WithFileUploads;
    public $photo;
    public $post;

    protected $rules = [
        'photo' => 'required|image|max:2048'
    ];

    public function mount($id)
    {
        $this->post = Post::find($id);
    }

    public function render()
    {
        return view('livewire.dashboard.featured-image-upload');
    }

    public function upload()
    {
        $this->validate();

        $image = $this->photo->storeAs('posts/', Str::random(30));
        $this->post->featured_image = $image;
        $this->post->save();
        session()->flash("message", "Featured image successfully uploaded");
    }
}

With the WithFileUploads trait, you can take advantage of the fluent file upload feature Livewire provides. $photo is the featured image we're dealing with while $post is the blog post we're creating. You see we're using mount to fetch this post.

The upload method is where we're actually doing the upload. First we validate the form to ensure there's an upload and the uploaded file is an image not more than 2MB. Secondly, we store the image in the storage/app/posts directory with a randomly generated string as its name. After saving the image, the storeAs method returns the path to the uploaded image, which we assigned to the post. Finally, we save the post with the updated featured image and flash a success message to the session.

Open the view file and enter this code into it:

<div class="p-4 mx-auto mt-3 h-4/5 md:p-8 md:w-3/5">
    <h2 class="my-2 text-lg font-semibold text-gray-700">Upload featured image</h2>
    <form wire:submit.prevent="upload" enctype="multipart/form-data">
        <div class="bg-white rounded shadow">
            @if (session()->has('message'))
                <div class="p-2 m-2 text-green-900 bg-green-600 bg-opacity-25 rounded-md">
                    {{ session('message') }} <a href="{{ route('new-post') }}">Add another one</a>
                </div>
            @endif
            <div class="p-8">
                <x-jet-label for="photo" class="flex items-center justify-center text-3xl border-2 border-dashed rounded-sm w-3/3 h-60 bg-gray-50">
                {{ __('Choose image') }}
                <x-jet-input type="file" id="photo" accept="jpg,png,gif"
                wire:model="photo" class="w-0 h-0"/>
                </x-jet-label>
                <x-jet-input-error for="photo" />
                </div>
            <div class="px-4 py-3 text-right bg-gray-50 sm:px-6">
                <x-jet-button class="inline-flex justify-center">
                    {{ __("Upload") }}
                </x-jet-button>
            </div>
        </div>
    </form>
</div>

There's nothing new here, except that we specified the enctype attribute to multipart/form-data. This is necessary to make file uploads successful.

Save the files. Create and submit a new post to see the featured image upload page:

Polishing Things Up

Previously, because we're automatically generating the posts for display, we used a static image in the public directory for all posts. Now that we're using the form to create posts the links to the images will be broken. This is because Livewire doesn't upload files to the public directory: it uploads it in the storage directory.

From the FeaturedImageUpload component, we said that images are uploaded to the storage/app/public/posts folder. However, you already know that for files to be accessible to the public, they need to be in the public folder. This is achieved by creating symlinks since file storage is done in the storage folder.

To create the symlink, add this to the $link array in config/filesystems.php:

public_path('posts') => storage_path('app/posts'),

Now, save the file and run the storage:link Artisan command to create the link:

php artisan storage:link

Our last work is to change the image source in both resources/views/livewire/post-item.blade.php and resources/views/livewire/detail.blade.php from:

<img src="{{ asset("storage/posts/$post->featured_image") }}" ...>

to:

<img src="{{ asset($post->featured_image) }}" ...>

You should now be able to see the images if you navigate to the home, category or detail page.

Congratulations! This brings us to the end of the seventh episode. In our next episode, we'll create and set up the remaining pages in the admin area.

Creating Your First Blog With TALL - Part Six

Alhassan Kamil — Tue, 06 Apr 2021 01:58:00 +0000

Hello! Welcome to this tutorial series. First of all, sorry for the delay in publishing this tutorial. I was quite busy for the last week and couldn't do it. Fortunately, I'm back this week to continue where we left.

This tutorial will build upon the previous episode. Remember you were able to create the home, item and categories pages using Livewire components in the last episode. You learnt how to display all posts in the homepage and show posts from a particular category in the categories page. You also learnt how to reuse Livewire components at multiple places by using the post item component in both the home and category pages.

In this episode, you'll turn your focus to displaying the details of individual posts. When you click a post from either the home page or the category page, the details page shows the details of the post.

At the end of this episode, you should be able to:

run select queries for a single row from the database using Eloquent.
use Tailwind CSS to create a responsive layout for a post.
create a mobile-first top navigation bar and nav menu for any website using Tailwind CSS.
use Alpine.js to make the navigation menu mobile-friendly.

OK, let's start our journey.:)

Creating the Detail Component

When a user clicks a post in either the home page or categories page, the person should be redirected to the Detail page. This is where they'll be able to read the post.

Technically speaking, the link to the detail page will pass the post's slug along and this will be captured by the Laravel Router and then passed to the Detail Component. This is what you'll use to retrieve the post from the database.

Enter the command to create the Detail component:

php artisan make:livewire Detail

Now open the Detail component from app/Http/Livewire. Make sure it contains this code:

<?php

namespace App\Http\Livewire;

use App\Models\Post;
use Livewire\Component;

class Detail extends Component
{
    public $post;

    public function mount($slug)
    {
        $this->post = Post::firstWhere('slug', $slug);
    }
    public function render()
    {
        return view('livewire.detail')
            ->layout("layouts/guest");
    }
}

First of all, you're using the Post model. You used the firstWhere method to get the post by its slug. This ensures only the first post matching the slug is returned(you're sure the post is what you asked for because each post has a unique slug).

If you can remember, in the last episode I made mention that Livewire automatically makes public properties in a component available in the view. Therefore, the $post member variable is readily available in detail.blade.php.

We also said that the mount method is called once the component is mounted. Therefore, it is the best place to initialize properties, run database queries and carry out other initialization in the component. When you bind a route with parameters to a Livewire component, the mount method can also be used to capture the argument(s) from the route and make them available to the component.

This is exactly what you've used the Detail component's mount method for - to capture the $slug parameter passed to the route.

Since the $post variable is available in the detail view, we now have to edit the resources/views/livewire/detail.blade.php view file to display the post.

Open the view file and enter this code into it:

<div class="mx-auto md:w-4/5 lg:w-3/5">
    <h2 class="mt-2 text-xl font-bold lg:text-2xl">
        {{ $post->title }}
    </h2>
    <div class="flex flex-row my-3">
        <div class="mr-2 text-gray-700">
            {{ $post->user->name }}
        </div>

        <div class="w-2 h-2 my-auto mr-1 text-xl 
                bg-gray-300 rounded-full"></div>

        <div class="my-auto mr-2 text-sm 
                text-gray-500" title="Category">
            {{ ucwords($post->category) }}
        </div>

        <div class="w-2 h-2 my-auto mr-1 text-xl bg-gray-300 
                rounded-full"></div>

        <div class="my-auto text-sm text-gray-500">
            {{ $post->published_date }}
        </div>
    </div>
    <img src="{{ asset("storage/posts/$post->featured_image") }}" 
            alt="{{ $post->title }}" 
                class="w-full my-4 rounded-sm max-h-96">
    <div>
        {!! $post->body !!}
    </div>
</div>

This is what each class utility means from the view:

mx-auto: centers the element it's been applied to on the horizontal axis. This is the same as applying auto to both margin-left and margin-right. my-auto will center it in vertical direction while m-auto does same on both axis.
w-{number} applies width: {number} to the element and h-{number} also applies height: {number}.
The sm:, md:, lg: prefixes apply responsive variants of the utility classes. So md:w-4/5 makes this element occupy 4/5th of the screen size in medium-sized devices.
m{side}-{number} is used to set margin of size {number} to {side}. The value for {side} can be t for top, b for bottom, r for right, l for left, x for horizontal, y for vertical or nothing at all to represent all sides.
text-xl and text-2xl makes the text extra-large and extra-extra-large(2x extra-large). Other text size utilities include text-xs, text-sm, text-base, text-lg, text-3xl up to text-9xl.
I discussed flex and flex-row in the previous episode. As a reminder, these arrange children of the element in a flex row.
All other utilities have been discussed before in the previous episodes.

Routing to the Detail Page

Now that the detail page is ready, all you have to do is change the action for the post-detail route. Open the routes/web.php routes file and change the post-detail named route from this:

Route::get('{slug}', function ($slug) {
    return view('welcome');
})->name('post-detail');

to the following:

Route::get('{slug}', Detail::class)->name('post-detail');

Save all the files and start both your database server and the built-in PHP server. The latter can be started with this command if you've forgotten:

php artisan serve

Now you should be able to see something like this if you click any post from the home page:

Creating a Navigation Bar for the Tall Blog

Though our blog is able to display pages as expected, wouldn't it be nice if you could navigate to the categories page and back to the home page without using the browser's back button? Or, perhaps, from the detail page to either categories or home pages? This would not only improve the user experience of the blog, it would also make it consistent with other websites on the internet.

Consequently, you're going to create navigation component for the navbar. However, this is not going to be a Livewire component: it's going to be a Laravel component. It's going to be a Laravel component because that's more suitable for such cases than a Livewire component.

Create an anonymous nav component in the resources/views/components directory. Name it nav.blade.php and put this code into it:

<nav x-data="{ isOpen: false }" @keydown.escape="isOpen = false"
    class="z-10 flex flex-wrap justify-between w-full p-4 shadow-md">

    <div class="mr-6 text-xl font-bold">
        <a href="{{ route('home') }}"
        class="grid grid-cols-3 gap-1 transition duration-500 hover:text-purple-500">
            <x-jet-application-logo class="w-8 h-8 border border-blue-300 rounded-full" />
            <div class="col-span-2">Tall Blog</div>
        </a>
    </div>
    <button x-on:click="isOpen = !isOpen" type="button" class="px-2 lg:hidden"
        :class="{ 'transition transform-180': isOpen }">
        <svg class="w-6 h-6 fill-current" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24">
            <path x-show="isOpen"
                d="M18.278 16.864a1 1 0 0 1-1.414 1.414l-4.829-4.828-4.828 4.828a1 1 0 0 1-1.414-1.414l4.828-4.829-4.828-4.828a1 1 0 0 1 1.414-1.414l4.829 4.828 4.828-4.828a1 1 0 1 1 1.414 1.414l-4.828 4.829 4.828 4.828z" />
            <path x-show="!isOpen"
                d="M4 5h16a1 1 0 0 1 0 2H4a1 1 0 1 1 0-2zm0 6h16a1 1 0 0 1 0 2H4a1 1 0 0 1 0-2zm0 6h16a1 1 0 0 1 0 2H4a1 1 0 0 1 0-2z" />
        </svg>
    </button>
    <div class="flex-grow w-full transition-all duration-500 ease-in lg:flex lg:items-center lg:w-auto"
        :class="{ 'block shadow-3xl': isOpen, 'hidden': !isOpen }" @click.away="isOpen = false" x-show.transition="true">
        <ul class="items-center justify-end flex-1 pt-4 space-y-4 lg:pt-0 list-reset lg:flex lg:space-y-0">
            <li class="py-2 md:py-0">
                <a href="{{ route('home') }}" class="mx-4 text-lg hover:text-indigo-500">Home</a>
            </li>
            <li class="py-2 md:py-0">
                <a href="{{ route('home') }}" class="mx-4 text-lg hover:text-indigo-500">
                    Login
                </a>
            </li>
        </ul>
    </div>
    </div>
</nav>

This code is pretty large. But don't worry, apart from a few snippets you've encountered most of the others before.

From the code:

The first attribute in the nav element is an Alpine.js attribute. What it does is that it defines a variable called isOpen with an initial boolean value of false. This is used to toggle the navigation menu on mobile devices.
The @keydown.escape="isOpen = false" is also an Alpine.js snippet that sets the isOpen to false when the Escape key is pressed while the nav menu is open on mobile. This will close the menu.
Next is the class attribute. Again, this makes use of Tailwind CSS utilities a lot. Explanation each utility is as follows:
1. z-10 sets the z-index CSS property. Accepted values are within [z-0, z-10,z-20, z-30, z-40, z-50 and z-auto].
2. flex-wrap is the Tailwind way of applying flex-wrap: wrap to a flex element.
3. all the other utilities have been looked at already.
The next div element serves as a container for the logo and site title. The font-bold utility you applied to it here makes the title font bold. Here are the others:
1. We decided to display the logo and site title in a grid of three columns with a gap between them(indicated by grid grid-cols-3 gap-1).
2. Also, the transition duration-500 hover:text-purple-500 adds a purple color transition of length 500ms to the title text on hover.
3. The application-logo Jetstream component has been reused here and is almost similar to the way you used it in the second episode. The only difference now is that you have added a blue border(indicated by border border-blue-300) to it.
4. The site title is the last element in this container. It takes two of the three grid columns, as indicated by the col-span-2 utility class.
Our next element is the button that displays and hides the menu on mobile devices:
1. You applied the x-on:click Alpine.js handler on it. This fires the onClick event, giving you the chance to toggle the isOpen variable (isOpen = !isOpen) to its opposite value(from true to false or vice versa).
2. By specifying lg:hidden you're hiding this element on large screen devices.
3. The next encounter is the :class Alpine.js attribute. This appends the values you define within it to the element's class HTML attribute, allowing you to add certain classes based on JavaScript variables. You've made use of this by adding a 180-degrees transform and transition to this button when isOpen is true.
4. The SVG element is made up of two path objects - a close sign and a hamburger sign representing closed and opened states of the menu, respectively. Thus, the first sign (close) is shown when isOpen is true while the second sign (hamburger) is shown when isOpen is false.
Finally, we come to the div that contains the menu. The only new things here(on the Alpine side) are the attributes @click.away="isOpen = false" and x-show.transition="true". The @click.away implies clicking away from this div closes the menu(it sets isOpen to false). x-show.transition="true" adds transition to the element when it's showing.

Now add the nav component to resources/views/layouts/guest.blade.php layout file:

<x-nav/>

This should come just after the opening body tag. Save all files and reload your webpages to see the navigation bar:

This brings us to the end of this episode. In our next episode, we'll create and set up the pages making up the dashboard for the blog.

Creating Your First Blog With TALL - Part Five

Alhassan Kamil — Mon, 29 Mar 2021 22:43:00 +0000

Hello and welcome to this episode of the tutorial series. In the previous episode you learnt how to create factories and seed our database with sample data. This episode will begin with building the UI part of our blog using Laravel Livewire components.

At the end of the tutorial, you should be able to:

Describe what a Livewire component is.
Create and modify Livewire components to suit your needs.
Use Tailwind CSS utility classes to practically layout elements in your Blade view files.

As usual, fasten up your seat belt and let's dive in. :)

Note: There is a starter project up to this episode which can be accessed on Github here

Introduction

Part Two Recap

Remember in part two of this tutorial series we configured the public facing routes to return the default Laravel Jetstream welcome page. If you also remember, there were exactly two routes for the public facing pages of our blog - the home and the category pages. The homepage will be a listing of our blog posts while the category page will list all blog posts of a particular category. You can always read part two of this tutorial series here if you missed that part.

You're going to work on those two pages and replace the welcome page with a more interesting listing of your blog posts for this episode, albeit with introduction to some Tailwind CSS utilities. OK. Read on.

Introduction to Livewire Components

Livewire components are reusable pieces of code that you can define once and use in different parts of your application. They are just like Laravel components but comes with the power of both Laravel and Livewire. By default, a Livewire component is created with a corresponding view file. Livewire component classes are also placed in the app/Http/Livewire directory while their corresponding views are placed in the resources/views/livewire directory.

Creating Livewire Components

Livewire components are created by running the make:livewire or livewire:make Artisan commands in your terminal:

php artisan make:livewire PostItem
// or ...
php artisan livewire:make PostItem

This creates the most basic Livewire component, which extends the base Livewire Component class and contains a render method - used for rendering views and inline text:

<?php // tall-blog/app/Http/Livewire/PostItem.php 
namespace App\\Http\\Livewire;

use Livewire\\Component;

class PostItem extends Component {
    public function render() {
        return view('livewire.post-item');
    }
}

and the corresponding view:

{{\-- tall-blog/resources/views/livewire/post-item.blade.php --}}
<div>
    {{\-- If you look to others for fulfillment, you will never truly be fulfilled. --}}
</div>

Adding the --inline option tells Livewire that your component is an inline component and won't be returning any view in its render method. So this:

php artisan make:livewire PostItem --inline

yields something like this:

...
public function render() {
    return <<<'blade'
            <div></div>
        blade;
}
...

It is important to understand that public properties in a Livewire component are readily available in the component's view file, so you don't need to pass it through the view method like you're used to do if you've worked with pure Laravel controllers:

// This:
class PostItem extends Component {
    public $post;
    public function render() {
        return view('livewire.post-item');
    }
}

// is the same as this:
class PostItem extends Component {
    public $post;
    public function render() {
        return view('livewire.post-item', ['post' => $post]);
    }
}

Rendering Livewire Components

Livewire components are meant to be reusable. As a result, you can use them anywhere you would a Laravel component. Rendering a component can be done by either using the <livewire:component-name /> tag syntax or by using the @livewire('component-name') blade directive syntax:

<div>
    <livewire:post-item />
</div>
{{-- Or --}}
<div>
    @livewire('post-item')
</div>

Passing Parameters to Components

You can pass parameters to a component by specifying those parameters like so:

<livewire:post-item :post="$post" />
{{-- or --}}
@livewire('post-item', ['post' => $post])

Now the $post variable will be available in the PostItem component and view.

Accessing Route Parameters

In a situation whereby you need to access route parameters like you would in a traditional Laravel controller, Livewire allows you to do that in the mount method:

class MyComponent extends Component {
    public $userId;

    public function mount($userId) {
        $this->userId = $userId;
    }

    public function render() {
        return view('livewire.my-component');
    }
}

This feature makes it so powerful for Livewire components to mimic the behavior of Laravel controllers and also makes it easy to make full page components.

Creating Our Blog's Components

Now that you have a solid understanding of Livewire components, let's move on to work on our blog. If you haven't yet done so from above, create your first Livewire component for the project by running this command in your terminal:

php artisan make:livewire PostItem

This component represents one post item from a list in the home and category pages. Open the component class in app/Http/Livewire/PostItem.php and add a public $post property to the beginning. The component class should look similar to this:

<?php // tall-blog/app/Http/Livewire/PostItem.php
namespace App\Http\Livewire;

use Livewire\Component;

class PostItem extends Component {
    public $post;

    public function render() {
        return view('livewire.post-item');
    }
}

As pointed out above, the $post property will now be readily available in the view file for use since it is declared public. Open the corresponding blade view file in resources/views/livewire/post-item.blade.php. Make sure it contains the following:

{{-- tall-blog/resources/views/livewire/post-item.blade.php --}}
<article class="flex flex-col mb-2 rounded-md shadow-md md:mb-0">
    <a href="{{ route('post-detail', ['slug' => $post->slug]) }}">
        <img src='{{ asset("storage/posts/$post->featured_image") }}' 
            alt="{{ $post->title }}" class="w-full h-56 rounded-t-md">
    </a>
    <div class="p-3">
        <h3 class="text-lg font-semibold text-gray-900">
            <a href="{{ route('post-detail', ['slug' => $post->slug]) }}">
                {{ $post->title }}
            </a>
        </h3>
        <p class="text-gray-800">
            <a href="{{ route('post-detail', ['slug' => $post->slug]) }}">
                {{ $post->excerpt }}
            </a>
        </p>
        <div class="flex flex-row justify-between mt-2">
            <a href="{{ route('category', ['category' => $post->category]) }}" 
                 class="px-2 text-sm text-indigo-900 bg-indigo-100 rounded">
                {{ $post->category }}
            </a>
            <small>
                {{ $post->published_date }}
            </small>
        </div>
    </div>
</article>

First of all, you can see that we're making use of the $post variable in this file, which contains a blog post entry. We're utilizing Tailwind CSS class utilities to style the root <article> element. In this case, we have laid its contents in a Flexbox with a flex-direction of col - meaning we want to lay the contents from the top to bottom. mb-2 is a utility class for 8-pixels margin-bottom value with rounded-md and shadow-md representing medium rounded and medium shadowed shapes respectively.

Next is the anchor element (a tag). We're referencing a named Route to route to the post detail page(using the route helper function) which uses the post's slug to construct the link. Remember we didn't create the post detail route so you would need to add it just below the homepage route:

Route::get('/', function () {
     return view('welcome');
})->name('home');

// Add below route
Route::get('{slug}', function ($slug) {
    return view('welcome');
})->name('post-detail');

Next in the tree is the image, whose width we have made full (100%) with w-full and whose height we have decided will be h-56 (equivalent to 224px) with its top rounded. The post image's src attribute points to an image in the posts folder which is in the storage symlink we created earlier. asset is also one of the helper functions that allows you to display assets(css, images, js) files in your blade views. The file itself is uploaded in the posts folder while its name is saved into the database.

The next block contains the title, excerpt, category and published date all wrapped in a nicely padded(with p-3) div element. Both the title and excerpt use a different shade of gray text color from Tailwind CSS's color utilities. The last thing worth noting is the fact that the category and published date of our post are also wrapped in a Flexbox div container which runs from left to right (row) with a justify-between utility which ensures that these two elements are placed at the extreme ends of both left and right of the containing div element.

The post item component is now done. Let's create another component that will list all the posts on the homepage. This component will fetch all the posts from the database and display each in the post item component we created above. Enter the command to create the show-posts component:

php artisan make:livewire ShowPosts

Open the created component at app/Http/Livewire/ShowPosts.php and make sure its contents is equal to this:

<?php // tall-blog/app/Http/Livewire/ShowPosts.php
namespace App\Http\Livewire;

use App\Models\Post;
use Livewire\Component;

class ShowPosts extends Component {
    public $posts;

    public function mount() {
        $this->posts = Post::where('is_published', true)->get();
    }
    public function render() {
        return view('livewire.show-posts')->layout("layouts/guest");
    }
}

The $posts property holds all our posts from the database, which we fetch when this component is mounted (this is why the query is put in the mount method). We're only interested in posts that are published. We have also specified the layout to use (i.e guest layout file). By default, Livewire uses the resources/views/layouts/app.blade.php layout file. However, because Jetstream adds authentication and other checks to that layout, using the app layout file without those checks in place will lead to errors, that's the reason we're using the resources/views/layouts/guest.blade.php layout file.

Now open the corresponding resources/views/livewire/show-posts.bladed.php blade view and enter the following in it:

<div class="gap-4 m-2 md:grid md:grid-cols-2 lg:grid-cols-4">
    @foreach ($posts as $post)
        @livewire('post-item', ['post' => $post], key($post->id))
    @endforeach
</div>

This one is simpler than you might have guessed. We're looping through the $posts collection and rendering each using the PostItem component we created earlier, passing the $post to its post parameter and giving its key the post id. The key is used to uniquely differentiate the current post item from the others and is very necessary when you, for example, want to toggle a post's visibility.

On the Tailwind part, we're displaying the posts in

a block container on small screens,
a grid container with two columns in medium screen devices and
a grid container with four columns in large+ screen devices

All these with a 16-px gap between each item. Of course, and an 8-pixel margin.

Now change the homepage route to the following:

...
Route::get('/', App\Http\Livewire\ShowPosts::class)->name('home');
...

Hook up your terminal, run php artisan serve and open your browser to http://127.0.0.1:8000 and you should see posts in the homepage:

Now create the last Livewire component, which will display all posts from a particular category, by running this Artisan command:

php artisan make:livewire CategoryPosts --inline

We have made the CategoryPosts component inline because it is going to reuse the show-posts component view file. Since there is nothing different between the two except filtering from the database, it is simpler using this approach.

Modify the CategoryPosts component to match the following:

<?php 
// tall-blog/app/Http/Livewire/CategoryPosts.php

namespace App\Http\Livewire;

use App\Models\Post;
use Livewire\Component;

class CategoryPosts extends Component {
    public $posts;

    public function mount($category) {
        $this->posts = Post::where('category', $category)
             ->where('is_published', true)
             ->get();
    }
    public function render() {
        return view('livewire.show-posts')
                 ->layout("layouts/guest");
    }
}

This is almost the same as the ShowPosts component except that we've changed the query to fetch based on the given category query string passed to the mount method. Change the category route to the following:

...
Route::get('categories/{category}', CategoryPosts::class)->name('category');
...

Start the built-in PHP server if it's not running:

php artisan serve

Now go back to your homepage and click on any category. It should send you to the category page displaying posts in the same category:

This brings us to the end of this episode. I hope you really enjoyed the tutorial and I'd love to see you reading the next episode. We post updates on both our Twitter and Facebook pages. If you don't mind, you can follow any of our social media pages to get notified when a new post is published.

Twitter: https://twitter.com/bandughana

Facebook: https://www.facebook.com/bandughana

Thank you and see you for the next post.

Creating Your First Blog With TALL - Part Four

Alhassan Kamil — Thu, 18 Mar 2021 01:12:00 +0000

Welcome back to today's episode. You learnt everything about setting up your database: creating models, different approaches to running database queries and running migrations in the last episode. This episode builds on that by teaching you how to create database factories and seed our database tables with sample data we can use for our blog.

You should be able to learn the following at the end of this tutorial:

What model factories are.
How to create and write model factories.
What database seeders are.
How to create and write database seeders.
How to run database seeders in order to seed our blog's database with some sample data.

Model Factories

Model factories in Laravel allow you to generate dummy/fake data using the Faker PHP library. The Faker library allows generating random data by specifying various attributes. With factories you define fake data to be generated for each attribute/column of your model. This not only saves you time of manually inserting database records, but enables you to save thousands of records in your database within seconds.

Creating Factories

Factories are created using the Laravel make:factory Artisan command, like so:

php artisan make:factory PostFactory

This creates the PostFactory factory in the database/factories folder with no model specified. To specify a model the factory belongs to, you can append the --model option to the above command. You can also create a factory when creating a new model with -f option and that model will eventually be created when the factory is run, as we did in the previous tutorial.

If you open the database/factories/PostFactory.php file you should notice the factory class definition is similar to this:

<?php

namespace Database\Factories;

use App\Models\Post;
use Illuminate\Database\Eloquent\Factories\Factory;

class PostFactory extends Factory
{
    /**
     * The name of the factory's corresponding model.
     *
     * @var string
     */
    protected $model = Post::class;

    /**
     * Define the model's default state.
     *
     * @return array
     */
    public function definition()
    {
        return [
            //
        ];
    }
}

A Laravel factory basically extends the base Factory class and defines two important members: a $model the factory will be creating and a definition method that defines the values to be applied when the factory is executed. The $model property will be automatically filled when you create the factory with the make:factory command by specifying the --model option and when you specify the -f option when creating a model.

Writing Factories

Though our factory is created, we'll have to tell Laravel how we want our data to be generated when this factory is run. To do that, we have to define each attribute/column of the Post model/post table and its corresponding value as an associative array of key-value pairs in the definition method of our factory.

The base Laravel Factory class has a Faker instance and so each factory has access to this Faker instance. You generate values for each of your columns using this Faker instance. So, the definition for our Post model's attributes will look like below:

// tall-blog/database/factories/PostFactory.php
...
...
...
    /**
     * Define the model's default state.
     *
     * @return array
     */
    public function definition()
    {
        return [
            'category' => $this->faker->text(100),
            'body' => $this->faker->paragraphs(15, true),
            'title' => $this->faker->sentence(15),
            'excerpt' => $this->faker->sentences(3, true),
            'featured_image' => "post.png",
            'published_date' => $this->faker->date(),
            'user_id' => 1,
        ];
    }

You notice that we've "hard-coded" some values such as the user_id and the featured_image fields. This is because auto-generating these values will not be the best since they depend on other factors. We've also left out the is_published field since we provided a default false value for it and want a post to stay unpublished until we decide to publish it.

One thing we'd want to add to our factory is a published state. This can be used to modify the default value of the is_published column(which, by default, is false) whenever we want to make a particular post as published. Add this method at the end of the PostFactory class to do that:

// tall-blog/database/factories/PostFactory.php
...
...
... 
/**
     * Indicates the post is published.
     *
     * @return \Illuminate\Database\Eloquent\Factories\Factory
     */
    public function published()
    {
        return $this->state(function (array $attributes) {
            return [
                'is_published' => true,
                'published_date' => now(),
            ];
        });
    }

You see that this method uses the state method provided by the base factory class, which accepts a closure containing the attributes we defined for this factory in the definition method as argument and returns the attributes to modify. Here we're just changing the is_published column to true and providing the current date time as the published date.

Using Factories

After creating and defining your factories, the next thing is to use them to create models. This can be achieved by using the factory method provided by the HasFactory trait we talked about in the previous episode like so:

//Creates a post without persisting to database
$post = Post::factory()->make();

// Same as above, but creates five(5) posts
$post = Post::factory()->count(5)->make();

// Same as above, but sets the published state to true
$post = Post::factory()->count(5)->published()->make();

//Creates a post and persists it to database
$post = Post::factory()->create();

// Same as persisting, but creates five(5) posts
$post = Post::factory()->count(5)->create();

// Same as persisting, but sets the published state to true
$post = Post::factory()->count(5)->published()->create();

Database Seeders

While model factories let you create sample data for your models, database seeders actually insert these data into the database, though seeders don't necessarily have to depend on factories to insert data. This means you can either use factories to seed data into your database or manually utilize Eloquent and the Query Builder to do so.

Seeders are placed in the database/seeders directory of your Laravel installation and, by default, contain a single run method - which is called when the db:seed command is executed. By default, Laravel creates a DatabaseSeeder class for you out of the box. You can use this class to run other seeders by providing them to the call method. This allows you to properly organize and arrange your seeders in any order you desire and also helps you run many seeders at once.

Creating Database Seeders

Just like other features of the Laravel framework, database seeders are created by running Artisan commands. You execute the make:seeder Artisan command and provide the name of the seeder to create, like so:

php artisan make:seeder PostSeeder

Writing Database Seeders

As I already mentioned above, seeders, by default, contains a single run method that is executed when the db:seed command is run. In the run method you insert your data by manually running Eloquent queries or by using factories. We're using the latter for this tutorial.

To insert data, we're going to make use of the PostFactory we created in the previous sections. Within the run method put this:

// tall-blog/database/seeders/PostSeeder.php
...
...
    /**
     * Run the database seeds.
     *
     * @return void
     */
    public function run()
    {
        Post::factory()
                ->count(20)
                ->published()
                ->create();
    }
...
...

We're creating 20 records of the Post model into our database whilst specifying that each post's state must be published, as opposed to the default unpublished behavior.

The last thing we want to do is open the DatabaseSeeder class and add the PostSeeder class to the call method's arguments in the run method:

// tall-blog/database/seeders/DatabaseSeeder.php
...
...
    /**
     * Seed the application's database.
     *
     * @return void
     */
    public function run()
    {
        $this->call([
            PostSeeder::class,
        ]);
    }
...
...

Though we could just run the PostSeeder without adding it here, doing it this way keeps your seeders organized and decoupled and can be run from a single central point.

Running the Seeder

Now that our seeder and factory are defined, we can proceed to seed our database with sample data. As pointed out already, seeders are run using the db:seed command and optionally providing the --class option, which is used to specify the seeder class we want to run:

php artisan db:seed

I didn't provide the --class option because Laravel runs the DatabaseSeeder class by default if it is not provided. Running the above will produce an output such as this:

kamil@kamil-sc650:~/Projects/Web/tall-blog$ php artisan db:seed
Seeding: Database\Seeders\PostSeeder
Seeded: Database\Seeders\PostSeeder (3,633.28ms)
Database seeding completed successfully.

Check your database to see the posts table filled with 20 posts.

This brings us to the end of the fourth episode of Creating Your First Blog With TALL tutorial series. Our next episode will teach you how to create and write your first Livewire components. See you then.

Creating Your First Blog With TALL - Part Three

Alhassan Kamil — Sat, 13 Mar 2021 02:01:00 +0000

Hello and welcome to the third episode of the Creating Your First Blog With TALL tutorial series. You learnt how to configure Jetstream, setup database connection, create routes, create a symlink and change the default Jetstream logo in the previous episode.

In this episode, you're going to learn how to setup and run migrations to create the tables for our blog and create the needed models for the project. At the end, you should be able to:

Get a basic understanding of the alternative ways Laravel lets you run database queries.
Know and explain what Laravel Eloquent models and migrations are.
Create models and migrations for any Laravel project
Run migrations for our project

Okay. Take a sip of coffee and let's dive in right away. :)

The Alternative Ways Database Queries are Run in Laravel

If you're coming from the traditional way of developing web apps using plain PHP, you may be blown away by how much Laravel eases the pain of handling database operations. Think about having to manually write SQL queries, take care of SQL vulnerabilities like SQL injection, and many others that you'll have to deal with, all taken care of by the framework.

In Laravel, you not only have to not manually write SQL commands in your PHP code, you have several options on how you want to run your database queries, including what you're used to when developing using plain PHP (albeit in a very simplified, easier way). You can write Laravel database operations using either raw SQL, the Laravel Query Builder or Eloquent models. We'll only look at the latter two in this tutorial. You can learn more about running raw SQL queries here.

Using Query Builder to Run Database Queries

The Query Builder is a general and convenient way of creating and running database queries. It can be used to run most of the database query operations supported by your database driver through the DB facade. The DB facade provides a convenient table method you can use to run queries against a given table. Other methods of the DB facade such as insert, update, select, where, delete, get etc can then be chained to the table method to run those respective queries like so:

use Illuminate\Support\Facades\DB;

// Select all users
$users = DB::table('users')->get();

// Select only approved users
$users = DB::table('users')->where('approved', true)->get();

// Delete all users
DB::table('users')->delete();

// Insert a new user
DB::table('users')->insert([
    'username' => 'awesomeuser',
    'email' => 'awesomeuser@example.com'
]);

// Update an existing user
$userAffected = DB::table('users')
              ->where('id', 2)
              ->update(['username' => 'mynewawesomename']);

Using Eloquent to Run Database Queries

Laravel Eloquent is an Object-Relational Mapper (ORM) that enables you to run database queries using models. Models allow you to store data and handles the logic that goes with it. With Eloquent, each table has a corresponding model class that deals with querying and storing data in that table. Since the rest of this tutorial will entirely be on using Eloquent, I'll leave explanation of Eloquent models here and continue with the other sections.

Creating Eloquent Models and Migrations

Eloquent Models

As I pointed out above, Eloquent models help you to store data and its related logic. Models act like data warehouse operators - any data entering/leaving the warehouse goes through them, they keep track of and update records, they can filter and sort items out, they know how to sanitize and check data for integrity and so much more.

Database Migrations

The Laravel docs does so well in explaining what migrations are and I won't repeat myself here. This is what the docs say about migrations:

Migrations are like version control for your database, allowing your team to define and share the application's database schema definition. If you have ever had to tell a teammate to manually add a column to their local database schema after pulling in your changes from source control, you've faced the problem that database migrations solve.

How to Create Eloquent Models

Like many other Laravel features, you can create Eloquent models by running Artisan commands from the terminal. To create a model, use the make:model command like so:

php artisan make:model ModelName

Where ModelName is the actual name of the model you want to create. This creates the given model (which extends \Illuminate\Database\Eloquent\Model) in the app\Models directory. You can optionally pass -m, -c, -f, -s to respectively create a migration, controller, factory or a database seeder(we'll explain these later in the coming series) in addition to the given model, or even combine these options, like so:

php artisan make:model ModelName -m // creates migration too
php artisan make:model ModelName -c // creates controller too
php artisan make:model ModelName -f // also creates a factory
php artisan make:model ModelName -s // also creates a database seeder
php artisan make:model ModelName -mfcs // creates migration, factory, controller and seeder

How to Create Migrations

Migrations are created by running the make:migration Artisan command, passing the name of the migration and an optional --path argument to specify where the migration should be placed. So creating a migration for ModelName above will look like below:

php artisan make:migration create_model_names_table

This will create a create_model_names_table migration in the database/migrations directory with two methods: up and down. up is used to add tables, indices and columns while down reverses these actions. For an in-depth understanding of migrations and models, please consult the official docs.

Creating Models and Migrations for Our Blog

Now that you have learnt what models and migrations are and how to create them, lets move on to create the models and migrations our blog will need. Because this is an introductory tutorial, our blog will only have one Post model in addition to the built-in User model (in a real world blog you'll definitely want to add other models such as category and tag models, but we don't wanna make this tutorial complicated and so we'll keep things as simple as possible.). And because there is a relationship between a blog post and the user who wrote it, we'll have to establish a database relationship here.

In any blogging system, a blog post belongs to a particular user. A user can have as many blog posts as they choose to. In this case of ours, a blog post cannot belong to multiple users, so we have a one-to-many relationship between users and posts. Laravel supports different kinds of entity relationships and one-to-many is just one of them we'll use in this tutorial.

To define the relationship a user has on posts, open the app/Models/User.php file and add this method to the end of it:

// tall-blog/app/Models/User.php
...
...
...
/**
* Get the posts for this user
*/
public function posts() {
    return $this->hasMany(Post::class);
}
...

This creates a one-to-many relationship to the Post model and allows us to get a user's posts by calling $user->posts on an existing $user object. If you see errors that the Post class doesn't exist just ignore it since that's what we're going to create next.

Create the Post model by running the make:model command and by specifying the -m, -s, and -f options:

php artisan make:model Post -mfs

This will create the Post model in app/Models. In addition, a new migration will be created in the database/migrations directory, a new model factory in database/factories and a database seeder in database/seeders.

Open the app/Models/Post.php model file and make sure its contents is exactly as follows:

// tall-blog/app/Models/Post.php
<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Factories\HasFactory;
use Illuminate\Database\Eloquent\Model;

class Post extends Model {
    use HasFactory;

    /**
     * Columns that are mass assignable
     */
    protected $fillable = [
        'title', 'excerpt', 'body', 'category',
        'featured_image', 'published_date',
        'is_published', 'user_id'
    ];

    /**
     * Returns the user for this post
     */
    public function user() {
        return $this->belongsTo(User::class)->withDefault();
    }
}

First of all, we're importing the HasFactory facade and the base Model class. Using the HasFactory facade here means the Post class has access to the factory method of the HasFactory facade, which is used to create factories. Our Post class extends the base Model class, which every model extends and therefore, will inherit all the methods available in the Model class. We have also defined the $fillable array property of the base Model class, which lists the attributes of the Post model that are mass assignable. Remember these attributes are also the columns for our posts table.

Lastly, we have defined a reverse one-to-many relationship between a post and its owner - a user. Just like the one-to-many relationship we defined for the User model, adding the reverse relationship this way enables us to query an existing Post object's user by simply calling $post->user.

We already learnt how to create migrations and we have even created the create_posts_table migration above when we run the make:model with the -m option specified. As I mentioned already, this migration is located in the database/migrations directory. Open it(Laravel prepends the current date to a migration's name when you create it, so you'd have to consider that when you're looking for the migration) and ensure the up method looks exactly as below:

// tall-blog/database/migrations/2021_03_10_141045_create_posts_table.php 
/**
 * Run the migrations.
 *
 * @return void
*/
public function up() {
    Schema::create('posts', function (Blueprint $table) {
        $table->id();
        $table->string('category');
        $table->string('excerpt');
        $table->longText('body');
        $table->string('title');
        $table->boolean('is_published')->default(false);
        $table->string('featured_image');
        $table->dateTime('published_date');
        $table->foreignId('user_id')->constrained();
        $table->timestamps();
    });
}

All we're doing here is creating the 'posts' table using the create method from the Schema facade. This method accepts the table to create as the first argument and a closure that uses the given Blueprint to define columns for the table. Ignoring all the column types (which you can learn here), we're also specifying an auto-incrementing ID column(from $table->id()) for our table, a foreign ID constraint that references the 'users' table at the database level(from $table->foreignId('user_id')->constrained()), and a timestamps columns (from $table->timestamps()) that will automatically create a created_at and updated_at columns for us.

Save the file. Ensure your database server is running and run the migrations to create the posts table:

php artisan migrate

If everything went well, you should get an output such as this:

kamil@kamil-sc650:~/Projects/Web/tall-blog$ php artisan migrate
Migrating: 2020_05_21_100000_create_teams_table
Migrated: 2020_05_21_100000_create_teams_table (3,058.26ms)
Migrating: 2020_05_21_200000_create_team_user_table
Migrated: 2020_05_21_200000_create_team_user_table (1,294.05ms)
Migrating: 2020_05_21_300000_create_team_invitations_table
Migrated: 2020_05_21_300000_create_team_invitations_table (3,464.26ms)
Migrating: 2021_03_10_141045_create_posts_table
Migrated: 2021_03_10_141045_create_posts_table (3,663.84ms)

You can check to see the created tables in the tall_blog database by using the terminal client for your database server or a GUI program such as phpMyAdmin, if you're using MySQL.

This brings us to the end of this episode of the Creating Your First Blog With TALL tutorial series and I hope you enjoyed the tutorial. In the next episode, you'll learn how to create model factories and database seeders in order to fill our database with sample data.

See you for the next post.

Creating Your First Blog With TALL - Part Two

Alhassan Kamil — Sun, 07 Mar 2021 02:56:00 +0000

You're warmly welcome to the second part of Creating Your First Blog With TALL (Tailwind CSS, Alpinejs, Laravel, Livewire) tutorial series. In the previous episode, we delved into some basic introduction to the TALL stack and set our development machine up for building websites with the TALL stack. We also looked at what each item in the stack does. For the benefit of doubt, you can always read part one of this tutorial series here if you haven't done so.

For this part of the tutorial series, you'll build upon the first part by configuring Laravel Jetstream and Fortify, database connection, routes, creating a symlink to the public folder to make file uploads possible and changing the default application logo.

At the end of this tutorial, you'll learn:

How to configure Jetstream and Fortify to enable profile photo uploads and email verification respectively.
How to configure a freshly installed Laravel database connection using the .env file.
How to create routes in a Laravel application.
How to create a symlink to the public folder for file uploads.
How to change the default Laravel Jetstream app logo to your own logo.

In the previous edition, I indicated we're going to create models and migrations but it seems this episode has gotten too long and adding that will make it worse, so I decided to send that part to the next session. OK, let's get going. :)

Configuring Jetstream and Fortify

Configuring Jetstream

When you ran php artisan jetstream:install in the first part of this tutorial series, Jetstream configuration files were published to your project's config folder. These include config files for both Jetstream (named jetstream.php) and Laravel Fortify (named fortify.php). The jetstream.php file is what we're going to configure in this section.

If you had gone to your profile page in the Jetstream dashboard after logging in, you'd notice that there is no field provided for you to upload your profile photo. The only fields you see are your name and email address:

Though uploading profile pictures is not available in the dashboard, Jetstream provides support for it out of the box and we're going to enable that feature.

To enable profile photo upload, while in the project root, go to the config folder and open jetstream.php. Scroll down until you find the features array. Uncomment Features::profilePhotos() so that the features array looks like this:

// tall-blog/config/jetstream.php    
/*
    |--------------------------------------------------------------------------
    | Features
    |--------------------------------------------------------------------------
    |
    | Some of Jetstream's features are optional. You may disable the features
    | by removing them from this array. You're free to only remove some of
    | these features or you can even remove all of these if you need to.
    |
    */

    'features' => [
        // Features::termsAndPrivacyPolicy(),
        Features::profilePhotos(),
        // Features::api(),
        // Features::teams(['invitations' => true]),
        Features::accountDeletion(),
    ],

Save the file and refresh your browser. You should now see a Photo field with a SELECT A NEW PHOTO button you can click to choose a picture:

As with all lines in Laravel configuration files, the features array has a comment block that explains what this line in the configuration does. Uncommenting a feature from this array enables it for your project and removing it or commenting it out does the reverse.

Configuring Fortify

While Jetstream deals with the user interface part of our scaffold, Fortify handles the authentication part. Thus, it's now time for us to enable email verification for all users so that users won't just provide invalid email addresses to register for our blog.

This is also done in a features array, just like in Jetstream, but in a different configuration file - fortify.php. Open the fortify.php configuration file in the config folder and ensure the Features::emailVerification() line is uncommented:

// tall-blog/config/fortify.php 
/*
    |--------------------------------------------------------------------------
    | Features
    |--------------------------------------------------------------------------
    |
    | Some of the Fortify features are optional. You may disable the features
    | by removing them from this array. You're free to only remove some of
    | these features or you can even remove all of these if you need to.
    |
    */

    'features' => [
        Features::registration(),
        Features::resetPasswords(),
        Features::emailVerification(),
        Features::updateProfileInformation(),
        Features::updatePasswords(),
        Features::twoFactorAuthentication([
            'confirmPassword' => true,
        ]),
    ],

Save the file and refresh your browser. Now every user who have registered on your blog will have to verify their email address for their account to be complete.

Configuring the .env File

Like many modern frameworks, Laravel keeps some common and secret configuration information in a .env file, also known as an environment file. These information include database connection details, cache driver details, mail configuration information, API keys and other app-level configuration details such as the app name, url and app secret key. All these, plus more, are housed in the .env file, which by default, is kept in the root of your project.

Note: The .env file may not be visible if you don't enable showing of hidden files on your computer. If that's the case, follow the documentation on how to enable display of hidden files for your operating system.

Specifically, what we want to do is change the default database connection and app-level details to the desired values so our blog can function properly. We do this by changing the values in the APP_ and DB_ prefix keys. These, in addition to the LOG_ prefix keys, are mostly located in the top section of the .env file. Change those DB_ and APP_ prefixed keys so they look the same as below:

# tall-blog/.env

APP_NAME="Tall Blog"
APP_ENV=local
APP_KEY=base64:wobqK/lLWqFYTNkUDRhtr5TDPqSyNC1p4YaV5CTFIR4=
APP_DEBUG=true
APP_URL=127.0.0.1:8000

LOG_CHANNEL=stack
LOG_LEVEL=debug

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=tall_blog
DB_USERNAME=root
DB_PASSWORD=root1234
...
...
...

Save the file and let's look at what each line means:

Line 1 is the app name. This is where you specify the name you want to give your blog.
Line 2 is the environment you're running. Here you specified that your app is running in the local environment. You may set this to other values such as staging, production, etc as and when you need to do so.
Line 3 sets the APP_KEY to a random 32-bit character string used for encrypting and securing sessions, tokens and other user level encryption.
Line 4 defines whether debugging is enabled (true, in this case) or not while Line 5 sets the app url.
The LOG_ keys on lines 7 and 8 are used for error logging configuration information. We specify the channel as 'stack'(which aggregates multiple log channels into a single channel) and the logging level as debug(verbose) since we're running in development environment.
Lines 10-15 are our database configs and are mostly self-explanatory:
1. DB_CONNECTION is the database connection name.
2. DB_HOST is the database host we'll running our database server on.
3. DB_PORT is the port the database host server runs on.
4. DB_DATABASE is the name our database we'll be connecting to in our blog.
5. DB_USERNAME and **DB_PASSWORD are the username and password, respectively, we'll use in connecting to our database.

To be able to follow along, you'll need to have a database server, preferably MySQL server, running on your computer with the tall_blog database and user with username root and password root1234 created. You can get a ready-made MySQL server bundled with other servers in a stack such as XAMPP, LAMP, MAMP or WAMP. These stacks are very easy to setup and use, and fulfills all requirements of the Laravel framework.

If you'd rather want to have everything Laravel requires and more, which won't mess up with your system, you can try either Laravel Homestead or Laravel Valet (for Mac). Homestead is a Vagrant box that incorporates all your server software on top of the Ubuntu distro in a Vagrant provisioned Virtual Machine. It runs on Linux, Windows and Mac systems. Valet, on the other hand, runs only on Mac and is even simpler to setup, very fast and very lightweight. So you may consider Valet if you're on Mac. The other obvious advantage of using Homestead or Valet is that you get a development environment that is similar to your production server. So you'd expect lesser hassles during deployment.

Adding Routes to Our Application

One of the benefits of modern frameworks is their routing capabilities and Laravel is not an exception. Routing in Laravel allows you to intercept HTTP requests and redirect those requests to the appropriate actionable closure or controller for handling.

Routing in any web application is as important as designing good user interfaces and putting everything in place to have a professional looking website. Frameworks with elegant routing systems take the pain of manually linking to hundreds and thousands of pages out of developers and simplify this process into pattern-based, definitive routes - making handling multitudes of similar urls a breeze.

In Laravel, all routes definitions are held in the routes folder. Web routes(user facing webpage routes) are defined in a file named web.php and this is where you'd spend most of your time when defining routes for your web application. When we installed Laravel, a default route for our homepage was already defined for us, that's why we're able to test out our installation.

Since we have decided to create our own routes, open and remove everything in the web.php file and replace the file's contents with the following:

// tall-blog/routes/web.php
<?php

use Illuminate\Support\Facades\Route;
/*
|--------------------------------------------------------------------------
| Web Routes
|--------------------------------------------------------------------------
|
| Here is where you can register web routes for your application. These
| routes are loaded by the RouteServiceProvider within a group which
| contains the "web" middleware group. Now create something great!
|
*/

Route::get('/', function () {
    return view('welcome');
});

Route::get('categories/{category}', function ($category) {
    return view('welcome');
});

Route::group(['prefix' => 'dashboard', 'middleware' => 'auth:sanctum'], function () {
    Route::get('/', function () {
        return view('dashboard');
    })->name('dashboard');

    Route::get('post/add', function () {
        return view('dashboard');
    });

    Route::get('category/add', function () {
        return view('dashboard');
    });
});

We started by making use of the Illuminate\Support\Facades\Route facade. This is all we need from Laravel to define our routes. The Route facade contains a lot of useful methods for defining our routes, popular among them are methods representing various popular HTTP request methods such as GET, POST, PUT, and DELETE. Methods that have no representation in the Routes facade but are in the HTTP specification can be specified by using the Route::any() method.

All our routes are defined with the Route::get() method, corresponding to the HTTP GET method. The Route::get() method makes a GET request to the given URI argument to be processed by the provided action argument. The action argument can be a closure, a controller or any PHP object that returns a value. For now, we decided to use closures because we haven't created any controller yet.

In the first route definition, we're routing to the homepage of our blog, for which we returned a view from a closure. The view helper function looks for the given view in the resources/views folder, parses it and returns its contents as HTML.

Our second route does the same thing, only that it routes to a given category. The {category} part in this URI is an example of a route parameter. Route parameters are passed to the action closure or controller and are available to them. An example request to this route will be http://127.0.0.1:8000/categories/web-design. In this example, the 'web-design' part will be made available to our closure.

Our third part of the routes is a bit complex. We're using route groups here. Defining routes this way let you group all your routes that have a common attribute ('prefix' and 'middleware' here) into an organized, single block of routes that are easier to trace and maintain. Thus, all the routes in this route group are for the dashboard part of our application - so they have the common prefix 'dashboard' before them.

We've also applied the auth:sanctum middleware to this route group. Meaning, all requests to any of the routes within this group will have to be authenticated in order to work.

Our first route in the group is the dashboard page itself. We decided to make it a named route. Naming routes makes it easier for you to refer to them in any part of your code without having to concatenate strings together. Currently, it returns the default dashboard view, as all other routes in the group. The last two routes are for adding posts and categories respectively(whose views we haven't implemented yet).

Creating A Symlink

Our next task is to create a symbolic link(symlink) from the storage/app/public folder to the public folder. This makes uploads in the storage/app/public folder available in the public folder(technically, this is not true since symlinks only point to the actual files and are not a copy of the actual files). To create the symlink, enter this command in your favorite terminal while in your project root:

php artisan storage:link

This should create the storage symlink in your public folder:

Changing the App Logo

If you had noticed when you were to login/register, the default Jetstream logo was displayed on both the registration and login pages. In deed, it's also utilized in the app dashboard.

If you're serious about being professional in your work, you wouldn't want to be showing this logo to your users. Jetstream doesn't stand in your way, either, to customize this logo to your liking. To be able to customize the logo, though, we have to publish Jetstream views. Enter this to do so:

php artisan vendor:publish --tag=jetstream-views

After running the above command, you should now see a new resources/views/vendor/jetstream folder with sub-folders housing various blade template views. All these blade views in the components sub-folder are Laravel components (learn more about components here). Our interest, for now, is on the files resources/views/vendor/jetstream/components/application-logo.blade.php, resources/views/vendor/jetstream/components/authentication-card-logo.blade.php, and resources/views/vendor/jetstream/components/application-mark.blade.php since they hold the default Jetstream logos.

First, open and delete everything in resources/views/vendor/jetstream/components/application-logo.blade.php, make sure it contains only the following:

// tall-blog/resources/views/vendor/jetstream/components/application-logo.blade.php
<img {{ $attributes }} src="{{ asset('logo.png') }}"/>

Save the file. Here, we're just linking to an image named logo.png(can be downloaded here) using the HTML img tag in the public folder. You can see that we used the Laravel asset() helper function (which, of course loads assets) to link to the image. The {{ and }} blade template tags basically act like the PHP echo statement. $attributes is a placeholder for a list of HTML attributes we may like to specify when we're to use this component.

Now open resources/views/vendor/jetstream/components/authentication-card-logo.blade.php and ensure its contents match below:

// tall-blog/resources/views/vendor/jetstream/components/authentication-card-logo.blade.php
<a href="/">
    <x-jet-application-logo class="w-24 h-24 rounded-full"/>
</a>

What we do here is making use of our application logo. We wouldn't want the logo to be oversized, so we use Tailwind CSS' width and height utilities to resize it and make it a circular shape. Since all the views in the resources/views/vendor/jetstream/components folder are Laravel components in the Jetstream namespace, we display the logo using a blade component tag here with the <x-jet-[component-name]/> syntax. Otherwise, component tags start with the string x- followed by the kebab case name of the component.

Let's now turn our attention to the last file we need to change - resources/views/vendor/jetstream/components/application-mark.blade.php. This file holds the logo displayed in the dashboard our application. Please open it and replace its content with:

// tall-blog/resources/views/vendor/jetstream/components/application-mark.blade.php
<x-jet-application-logo class="w-20 h-20"/>

This is the same as we did for the authentication card, the only difference is that we've reduced the size of the logo and didn't add the circular shape.

Now if you visit the login and registration pages you'll see the change:

This is the dashboard page:

Congratulations on the journey so far. It's been a rough one and I am happy you read to this end. In our next episode, you're going to learn how to create models and migrations. You'll also learn how to run these migrations in order to create the tables we'll need for this blog. Thank you and see you for the next episode.

Creating Your First Blog With TALL - Part One

Alhassan Kamil — Wed, 03 Mar 2021 15:32:00 +0000

Welcome to the first part of Creating Your First Blog With TALL (Tailwind CSS, Alpinejs, Laravel, Livewire) tutorial series. This tutorial takes you through introduction to the TALL stack, how it can help you ship products faster and setting up the TALL stack in your development environment.

After the end of this tutorial, you'll learn:

What constitutes the TALL stack and what each is in developing web apps
The benefits you gain when using the TALL stack to create web apps
How to setup the TALL stack using Laravel Jetstream on your development machine.
How to add Jetstream authentication and configure it for our new Laravel app

In addition, you'll be prepared enough for the next part of this tutorial series.

Let's get going.

Note: This tutorial assumes you already have Composer installed on your system. If Composer isn't installed on your computer, follow the instructions on their website to install it. Prior knowledge in Laravel and entering terminal commands is also assumed.

Introduction to the TALL stack

The TALL stack is a combination of both front-end and back-end libraries/frameworks that makes developing web apps a breeze. TALL is an acronym for Tailwind CSS, Alpine.js, Laravel and Livewire.

As you might have guessed, the back-end framework here is Laravel, while Alpine.js and Tailwind CSS are front-end libraries. Laravel Livewire is a bridge between the front-end and the Laravel back-end and brings dynamic data binding to Laravel so you can achieve reactivity and interactivity from the user facing parts of your website with Laravel, instead of using JavaScript.

Tailwind CSS

Tailwind CSS is a utility-based CSS framework that takes the hassles of using CSS out of your way. While using Tailwind CSS, you may decide not to write a single line of CSS code. This means you're not even required to have an extensive knowledge of CSS (apart from basic knowledge of CSS classes and other attributes) to use Tailwind CSS.

With Tailwind CSS, the possibilities of what you can design are unlimited. What you can do is only limited by your level of creativity and imagination!

Alpinejs

Alpinejs is the Tailwind of JavaScript libraries. It's a very small JavaScript library you can use in place of larger ones such as Vue.js and React to achieve interactivity and responsiveness for your web app.

Alpinejs takes the utility-first approach used by Tailwind CSS to make using JavaScript in your webpages easier. Instead of writing functions and class in a script tag or a .js file, you expressively write your JavaScript code in HTML tags as if they were HTML attributes.

Laravel

The Laravel framework is a PHP framework that brings simplicity, robustness and productivity to developing modern websites. Laravel is a matured framework with a very large community of developers, extensive but simple to grasp documentation and several official packages that helps in your website development cycle.

Using Laravel means that it is easy to get answers to questions you may face when developing your websites. You also have access to a large ecosystem of free, opensource packages that make it faster to ship and deploy web apps to production. What's more, you get all the benefits PHP has on the web such as more hosting and deployment options, server affordability, support and many others.

Laravel Livewire

Laravel Livewire lets you develop modern, dynamic, reactive user interfaces without having to learn new JavaScript frameworks such as Vue.js and React. You write all your code in PHP/Laravel and Livewire handles the JavaScript part for you.

If you have worked with Vue.js before, you probably know how data binding helps make your work easier as developer. Livewire supports data binding (best known as model binding) to forms, adding form validations, hassle-free file uploads, beautiful pagination and a bunch of other features.

Livewire separates your code into components so you get a well-structured, modular code when using it. Similar to Laravel components, the idea of Livewire components is such that each component carries out a particular action, but you're free to use components as the only view for webpages and even perform different actions in a component.

Benefits of the TALL stack

I believe you can already deduce the benefits of each of these tools from their explanations above. If you can't still figure out, here are some of the advantages of the TALL stack:

Helps you ship web apps faster.
Makes you more productive as a web developer
Takes care of all parts of the web development cycle: front-end, back-end and UX.
Takes care of securing your web applications.
Takes interactivity and responsive web design to a new level
And so many others

Setting up Our Development Environment

Laravel Jetstream is a Laravel scaffolding package providing authentication and API support out of the box for Laravel web applications. Jetstream comes bundled with either the Inertia stack or Livewire, plus Tailwind CSS and Alpine.js. We'll be using the Livewire stack for this tutorial series.

To install the Jetstream starter kit, we first have to download the Laravel installer:

composer global require laravel/installer

This downloads the Laravel executable into Composer's system-wide vendor directory. To make the executable available globally, we have to add the Composer vendor/bin directory to our $PATH. Depending on your development machine, the Composer vendor/bin directory is in one of the following:

macOS: $HOME/.composer/vendor/bin
Windows: %USERPROFILE%\AppData\Roaming\Composer\vendor\bin
Linux: $HOME/.config/composer/vendor/bin or $HOME/.composer/vendor/bin

For adding this directory to your $PATH, please consult the documentation for your Operating System.

Once you have added Composer vendor/bin directory to your path, navigate to a folder you'd like your project to be hosted, such as home/Projects on Linux or Documents/Projects on Windows. Create a new Laravel project with the following command in a terminal/Command Prompt:

laravel new tall-blog

Wait for the required dependencies to be installed. When the installation is done, you should get something like this:

kamil@kamil-sc650:~/Projects/Web$ laravel new tall-blog
 _                              _
| |                            | |
| |    __ _ _ __ __ ___  _____| |
| |   / _` | '__/ _` \ \ / / _ \ |
| |___| (_| | | | (_| |\ V / __/ |
|______\__,_|_| \__,_| \_/ \___|_|

Creating a "laravel/laravel" project at "./tall-blog"
Installing laravel/laravel (v8.5.9)
 - Installing laravel/laravel (v8.5.9): Extracting archive
Created project in /home/kamil/Projects/Web/tall-blog
> @php -r "file_exists('.env') || copy('.env.example', '.env');"
Loading composer repositories with package information
Updating dependencies
Lock file operations: 105 installs, 0 updates, 0 removals
 - Locking asm89/stack-cors (v2.0.2)
 - Locking brick/math (0.9.2)
 - Locking dnoegel/php-xdg-base-dir (v0.1.1)
 - Locking doctrine/inflector (2.0.3)
 - Locking doctrine/instantiator (1.4.0)
 - Locking doctrine/lexer (1.2.1)
 - Locking dragonmantank/cron-expression (v3.1.0)
 - Locking egulias/email-validator (2.1.25)
 - Locking facade/flare-client-php (1.3.7)
 ...
Writing lock file
Installing dependencies from lock file (including require-dev)                                                   
Package operations: 105 installs, 0 updates, 0 removals
 - Downloading symfony/var-dumper (v5.2.3)
 - Downloading symfony/string (v5.2.3)
 - Downloading symfony/console (v5.2.3)
 - Downloading symfony/css-selector (v5.2.3)
 - Downloading symfony/routing (v5.2.3)
 - Downloading symfony/process (v5.2.3)
 - Downloading symfony/mime (v5.2.3)
 - Downloading symfony/http-foundation
 ...
 - Installing doctrine/inflector (2.0.3): Extracting archive
 - Installing doctrine/lexer (1.2.1): Extracting archive
 - Installing symfony/polyfill-ctype (v1.22.0): Extracting archive
 - Installing webmozart/assert (1.9.1): Extracting archive
 - Installing dragonmantank/cron-expression (v3.1.0): Extracting archive
 - Installing symfony/polyfill-php80 (v1.22.0): Extracting archive
 - Installing symfony/polyfill-mbstring (v1.22.0): Extracting archive
 - Installing symfony/var-dumper (v5.2.3): Extracting archive
 - Installing symfony/polyfill-intl-normalizer (v1.22.0): Extracting archive
 - Installing symfony/polyfill-intl-grapheme (v1.22.0): Extracting archive
 - Installing symfony/string (v5.2.3): Extracting archive
 - Installing psr/container (1.0.0): Extracting archive
 - Installing symfony/service-contracts (v2.2.0): Extracting archive
 ...
63 package suggestions were added by new dependencies, use `composer suggest` to see details.                    
Generating optimized autoload files
> Illuminate\Foundation\ComposerScripts::postAutoloadDump
> @php artisan package:discover --ansi
Discovered Package: facade/ignition
Discovered Package: fideloper/proxy
Discovered Package: fruitcake/laravel-cors
Discovered Package: laravel/sail
Discovered Package: laravel/tinker
Discovered Package: nesbot/carbon
Discovered Package: nunomaduro/collision
Package manifest generated successfully.
74 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
> @php artisan key:generate --ansi
Application key set successfully.

Application ready! Build something amazing.

If you've got errors during the previous stage, make sure your system meets the system requirements specified here on the Laravel website.

Spin up the built-in PHP server and let's see our starter website:

php artisan serve

Now open http://127.0.0.1:8000 to see our newly crafted Laravel site.

Our next task is to install Laravel Jetstream. While still in the root of our project, enter this in your terminal:

composer require laravel/jetstream

Again, if everything went smoothly, you get something like this:

kamil@kamil-sc650:~/Projects/Web$ cd tall-blog && composer require laravel/jetstream
Using version ^2.1 for laravel/jetstream
./composer.json has been updated
Running composer update laravel/jetstream
Loading composer repositories with package information
Updating dependencies
Lock file operations: 9 installs, 0 updates, 0 removals
 - Locking bacon/bacon-qr-code (2.0.3)
 - Locking dasprid/enum (1.0.3)
 - Locking jaybizzle/crawler-detect (v1.2.104)
 - Locking jenssegers/agent (v2.6.4)
 - Locking laravel/fortify (v1.7.5)
 - Locking laravel/jetstream (v2.1.3)
 - Locking mobiledetect/mobiledetectlib (2.8.35)
 - Locking paragonie/constant_time_encoding (v2.4.0)
 - Locking pragmarx/google2fa (8.0.0)
Writing lock file
Installing dependencies from lock file (including require-dev)                                                   
Package operations: 9 installs, 0 updates, 0 removals
 - Downloading laravel/jetstream (v2.1.3)
 - Installing dasprid/enum (1.0.3): Extracting archive
 - Installing bacon/bacon-qr-code (2.0.3): Extracting archive
 - Installing jaybizzle/crawler-detect (v1.2.104): Extracting archive
 - Installing paragonie/constant_time_encoding (v2.4.0): Extracting archive
 - Installing pragmarx/google2fa (8.0.0): Extracting archive
 - Installing laravel/fortify (v1.7.5): Extracting archive
 - Installing mobiledetect/mobiledetectlib (2.8.35): Extracting archive
 - Installing jenssegers/agent (v2.6.4): Extracting archive
 - Installing laravel/jetstream (v2.1.3): Extracting archive
Generating optimized autoload files
> Illuminate\Foundation\ComposerScripts::postAutoloadDump
> @php artisan package:discover --ansi
Discovered Package: facade/ignition
Discovered Package: fideloper/proxy
Discovered Package: fruitcake/laravel-cors
Discovered Package: jenssegers/agent
Discovered Package: laravel/fortify
Discovered Package: laravel/jetstream
Discovered Package: laravel/sail
Discovered Package: laravel/tinker
Discovered Package: nesbot/carbon
Discovered Package: nunomaduro/collision
Package manifest generated successfully.
75 packages you are using are looking for funding.
Use the `composer fund` command to find out more!

Congratulations! The Jetstream package has been installed. Now we have to run the jetstream:install Artisan command with livewire as an option to use Jetstream with the Livewire stack:

php artisan jetstream:install livewire

You can append --teams to the above command if your blog needs a team support. After pressing Enter/Return, you should get an output such as this:

kamil@kamil-sc650:~/Projects/Web/tall-blog$ php artisan jetstream:install livewire
Migration created successfully!
./composer.json has been updated
Running composer update livewire/livewire laravel/sanctum
Loading composer repositories with package information
Updating dependencies
Lock file operations: 2 installs, 0 updates, 0 removals
 - Locking laravel/sanctum (v2.9.0)
 - Locking livewire/livewire (v2.3.16)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 2 installs, 0 updates, 0 removals
 - Downloading livewire/livewire (v2.3.16)
 0/1 [>---------------------------]  0%
 1/1 [============================] 100% - Installing laravel/sanctum (v2.9.0): Extracting archive
 - Installing livewire/livewire (v2.3.16): Extracting archive
 0/2 [>---------------------------]  0%
 2/2 [============================] 100%Generating optimized autoload files
> Illuminate\Foundation\ComposerScripts::postAutoloadDump
> @php artisan package:discover --ansi
Discovered Package: facade/ignition
Discovered Package: fideloper/proxy
Discovered Package: fruitcake/laravel-cors
Discovered Package: jenssegers/agent
Discovered Package: laravel/fortify
Discovered Package: laravel/jetstream
Discovered Package: laravel/sail
Discovered Package: laravel/sanctum
Discovered Package: laravel/tinker
Discovered Package: livewire/livewire
Discovered Package: nesbot/carbon
Discovered Package: nunomaduro/collision
Package manifest generated successfully.
76 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
Copied Directory [/vendor/laravel/sanctum/database/migrations] To [/database/migrations]
Copied File [/vendor/laravel/sanctum/config/sanctum.php] To [/config/sanctum.php]
Publishing complete.

Livewire scaffolding installed successfully.
Please execute "npm install && npm run dev" to build your assets.

After this, we also need to install and build NPM dependencies and migrate our database. Enter this into your terminal to do that:

npm install
npm run dev
php artisan migrate

When NPM dependencies have been installed, built and migrations run, our blog scaffolding process is now done. Out of the box, we've got both traditional and two-factor authentication, session management and API support for our Laravel blog for free :).

If not running, start up the built-in PHP server using php artisan serve and point your browser to http://127.0.0.1:8000 . You should be able to get something like this:

This means our blog scaffolding process has been successful. Click on Register link in the top right corner of the navigation bar to register for a new account:

Enter your details and click Register button to register and login.

If everything went on successful, you'll be redirected to the ready-made Jetstream dashboard:

Feel free to explore the features of your newly created Jetstream powered dashboard. In particular, you'd definitely want to go through the navigation bar menu links to see what they have to offer.

This completes the first episode of our Creating your first blog with TALL tutorial series. Our next episode will be configuring Jetstream and Fortify (used for authentication) in order to enable profile photos and email verification support, setup database and other configurations in the .env file, configure our routes, create a symlink to the public folder to make file uploads possible, change the default application logo, and create the necessary models and migrations for our blog.

Thank you for reading! See you for the next tutorial.