DEV Community: Stefan Ashwell

No cookies please: How to stop Laravel setting default cookies

Stefan Ashwell — Fri, 22 Jan 2021 09:05:31 +0000

This post includes affiliate links; I may receive compensation if you purchase products or services from links provided in this article.

We've all seen them a million times and they annoy us way more than they solve a problem.

Cookie consent banners have become so common these days that half the time I just click the button to get rid of them without a second thought.

When I started my website I set out with a clear set of goals in mind - simple, quick and informative. One thing that doesn't fit in with those ideals is a horrible cookie banner. So I looked for a solution.

When do you need a cookie banner?

As far as I understand it (and I'm no legal expert!) you need a cookie consent banner when you store information in cookies or via other methods (such as local storage) and they are not required in order for the site to function.

You don't need to have one when you only use cookies in order for the site to function correctly - such as to remember a user is logged in.

So what did I decide?

My site is intentionally simple.

Even though it's built in Laravel, it's essentially a static site.

There's no logins or other bells and whistles.

Therefore I decided there was no reason to store cookies at all - removing the requirement to have a cookie consent banner. Simple.

Stop Laravel setting cookies

Even if you're not using any features that require cookies, by default Laravel sets two - a laravel_session cookie, and an xsrf_token cookie.

I don't need the session cookie because I'm not using sessions for anything on the site.

There are also no forms on the website, so the xsrf token is not required either.

To stop Laravel creating these cookies, first I commented the following lines in app/Http/Kernel.php

'web' => [
    \App\Http\Middleware\EncryptCookies::class,
    \Illuminate\Cookie\Middleware\AddQueuedCookiesToResponse::class,
    //\Illuminate\Session\Middleware\StartSession::class,
    // \Illuminate\Session\Middleware\AuthenticateSession::class,
    //\Illuminate\View\Middleware\ShareErrorsFromSession::class,
    //\App\Http\Middleware\VerifyCsrfToken::class,
    \Illuminate\Routing\Middleware\SubstituteBindings::class,
],

Then, I set the session driver to array in my .env file:

SESSION_DRIVER=array

As simple as that.

What about stats?

The usual culprit for storing cookies that aren't required for a site to function are those set by a stats service such as Google Analytics.

Obviously I want to see how my site's performing, how visitors find the site, see which posts are popular and what type of content goes down well with visitors.

That shouldn't mean my site has to set intrusive cookies.

And so I looked around for an alternative and found Fathom.

Fathom take privacy very seriously, and their stats service doesn't store any cookies at all. It tracks visitors anonymously so I can see a simple set of stats about my site - visitors, referrals, bounce rate, time on site, country etc.

This means everyone can be happy - no cookie banner, no intrusive cookies. It even respects visitors who have opted out of tracking services.

Thanks for reading, hopefully you found this article useful. If you want to chat about anything in this article or about anything to do with code leave me a comment below or you can find me on Twitter @CodingWithStef.

Creating a Markdown Driven Blog using Laravel 8

Stefan Ashwell — Tue, 19 Jan 2021 11:24:35 +0000

In this post I’m going to walk you through how I created my blog using Markdown files with Laravel 8, and why I chose to go that route instead of a blogging platform like Wordpress or Ghost.

The result was a really quick site build and something very simple for me to maintain.

Why Markdown with Laravel?

So the first question is why I went this route?

Well, I wanted to get something live as quickly as possible. I’ve tried blogging in the past and got too hung up in the site’s design or features.

This time I wanted to focus on the content.

The sensible choice would be Wordpress or Ghost right? Actually, not for me. It’s a long time since I’ve built anything in Wordpress, and while I’ve played around with Ghost and it looks very cool there would still be a learning process.

Everything I build these days is in Laravel, so the quickest way to get it up and live would be to go that way.

Plus I don’t need a full CMS interface to manage the content. I’m more than happy to write posts in Markdown in my text editor.

And so I got to work building something that would read Markdown files from a directory and display them on screen. Nice and simple.

Reading Markdown Files

So the main challenge with this build was to figure out how to read Markdown files in a directory.

I knew I’d need to do this in 2 different situations.

First, getting a list of posts in date order for listing screens. Secondly, reading a single file to display a single post.

I decided to include the publish date in the file names, and also to use the file names as the post slugs. For example:

2021-01-16-creating-a-markdown-blog-with-laravel-8.md

Then, I created a Post class, and in the constructor created a collection of all of the filenames in the app/Posts directory. Here’s the code:

use Illuminate\Support\Facades\File;

class Post
{
    public $filenames;

    public function __construct()
    {
        $this->filenames = collect(File::allFiles(app_path('Posts')))
            ->sortByDesc(function ($file) {
                return $file->getBaseName();
            })
            ->map(function ($file) {
                return $file->getBaseName();
            });
    }
}

Here I’m using the Illuminate\Support\Facades\File class to list files in the app/Posts directory. Then using sortByDesc I ensure they are in date order.

Finally, I use the map method to store just the file name in the collection array.

Creating the Listings Pages

There are 2 types of listings pages - the homepage lists all posts, and the category pages list posts in a particular category. I started by looking at the first situation.

To achieve this, I would need to use the Illuminate\Filesystem\Filesystem class, so I create an instance of this in the constructor:

use Illuminate\Support\Facades\File;
use Illuminate\Filesystem\Filesystem;

class Post
{
    public $filenames;
    public $filesystem;

    public function __construct()
    {
        $this->filenames = collect(File::allFiles(app_path('Posts')))
            ->sortByDesc(function ($file) {
                return $file->getBaseName();
            })
            ->map(function ($file) {
                return $file->getBaseName();
            });

        $this->filesystem = new Filesystem();
    }
}

Next, I created a getLatest method on the Post class:

public function getLatest($limit)
{
    $posts = [];

    foreach ($this->filenames->take($limit) as $filename) {
        // Build $posts array
    }

    return collect($posts);
}

This method gets a number of posts specified by the limit parameter. Because the filenames are a collection I can use the take method for this.

Next, I created a getPostData method to read each post:

use League\CommonMark\Environment;
use League\CommonMark\CommonMarkConverter;
use League\CommonMark\Extension\Attributes\AttributesExtension;

...

public function getPostData($filename)
{
    $file = $this->filesystem->get(app_path('Posts/' . $filename));

    $post['slug'] = str_replace('.md', '', $filename);

    $environment = Environment::createCommonMarkEnvironment();
    $environment->addExtension(new AttributesExtension());
    $converter = new CommonMarkConverter([], $environment);

    $post['body'] = $converter->convertToHtml($file);

    return $post;
}

As you can see here I am making use of the league/commonmark package to read the Markdown file and convert it to HTML.

composer require league/commonmark

What's the AttributesExtension?

The attributes extension allows me to add attributes to elements in the Markdown itself. I use it to create callouts just like this one by assigning the .callout class to a blockquote. You can read more here.

I also generate the slug by removing the .md extension.

An array of post data is returned, and so back in the getLatest method I call getPostData on each post.

public function getLatest($limit)
{
    $posts = [];

    foreach ($this->filenames->take($limit) as $filename) {
        $posts[] = $this->getPostData($filename);
    }

    return collect($posts);
}

Now, in my HomepageController I call the getLatest method to get the 5 latest posts, and pass the returned data to the view:

namespace App\Http\Controllers;

use App\Models\Post;

class HomepageController extends Controller
{
    public function index()
    {
        $postClass = new Post;

        $posts = $postClass->getLatest(5);

        return view('homepage', compact('posts'));
    }
}

Using Frontmatter

This was a good start, however I didn’t want to display the full HTML in the listings. I also wanted to categorise posts.

Enter frontmatter - a section of information at the top of the Markdown file where I could set any of this information. It looks like this:

---
title: "Creating a Markdown Driven Blog using Laravel 8"
published: 2021-01-16
category: Laravel
excerpt: In this post I’m going to walk you through how I created this website using Markdown files with Laravel 8, and why I chose to go that route instead of a blogging platform like Wordpress or Ghost.
---

Now you can see I have the post title, date, category and an excerpt set.

This information can be retrieved using the spatie/yaml-front-matter package.

composer require spatie/yaml-front-matter

So let’s use this when building the post information:

use Spatie\YamlFrontMatter\YamlFrontMatter;

...

public function getPostData($filename)
{
    $file = $this->filesystem->get(app_path('Posts/' . $filename));
    $object = YamlFrontMatter::parse($file);

    $post['meta'] = $object->matter();
    $post['slug'] = str_replace('.md', '', $filename);

    $environment = Environment::createCommonMarkEnvironment();
    $environment->addExtension(new AttributesExtension());
    $converter = new CommonMarkConverter([], $environment);

    $post['body'] = $converter->convertToHtml($object->body());

    return $post;
}

As you can see, the file’s contents are now parsed by YamlFrontMatter first.

I’ve added meta to the returned array that contains all of these fields.

And the body HTML is generated by passing the body of the parsed post rather than the entire file.

This means I can now update my homepage view to just display the title, date, category and excerpt.

Adding Categories

Next, let’s look at categories. We have the category in our frontmatter, I would like to have dedicated category pages using the URL articles/{category} so the first step is to create that route:

use App\Http\Controllers\CategoryController;

...

Route::get('articles/{category}', [CategoryController::class, 'index']);

So in order to do this filtering I need to read each file. So I created a getCategory method in the Post class:

public function getCategory($category, $limit)
{
    $posts = [];

    foreach ($this->filenames as $filename) {
        $posts[] = $this->getPostData($filename);
    }

    return collect($posts)->where('category', ucwords($category))->take($limit);
}

This method loops through all of the posts getting all data. Then on the collection returned I use the where method to filter the posts that are returned.

In order for this to work, I expanded the getPostData method to set a category key in the post array, so that it's there for the where method to filter by:

public function getPostData($filename)
{
    $file = $this->filesystem->get(app_path('Posts/' . $filename));
    $object = YamlFrontMatter::parse($file);

    $post['meta'] = $object->matter();
    $post['category'] = $object->matter('category');
    $post['slug'] = str_replace('.md', '', $filename);

    $environment = Environment::createCommonMarkEnvironment();
    $environment->addExtension(new AttributesExtension());
    $converter = new CommonMarkConverter([], $environment);

    $post['body'] = $converter->convertToHtml($object->body());

    return $post;
}

Now, in the CategoryController I can call the getCategory method to get the latest posts in the category requested:

namespace App\Http\Controllers;

use App\Models\Post;

class CategoryController extends Controller
{
    public function index($category)
    {
        $postClass = new Post;

        $posts = $postClass->getCategory($category, 5);

        if ($posts->count() == 0) {
            return redirect('/');
        }

        return view('category', compact('posts'));
    }
}

Note: Right now I think this approach is fine as I only have a small number of posts on the site. As the site grows with more posts I would like to look into a more efficient way to achieve this filtering so I don’t need to process every single post first!

Post Detail

Finally, I needed a post detail page. Here’s the route:

use App\Http\Controllers\ArticleController;

...

Route::get('{slug}', [ArticleController::class, 'index']);

And then the ArticleController calls getPostData on the filename requested by the slug in the URL:

namespace App\Http\Controllers;

use App\Models\Post;

class ArticleController extends Controller
{
    public function index($slug)
    {
        $postClass = new Post;

        $post = $postClass->getPostData($slug . '.md');

        return view('article', compact('post'));
    }
}

Nice and simple!

Future Improvements

This setup allowed me to get live and start posting content super quickly - a couple of evenings work and I was ready to go live!

As mentioned in a note above, I’m not 100% happy with the category filtering and I’d like to look into that as it could impact performance as the number of posts increase.

That said, another improvement I am considering is to use the spatie/laravel-export package to generate a static site as part of my deployment process.

This way I should be able to improve performance even further on the site by hosting just static files. But it would reduce the impact of any potential category filtering issues as it would only happen at build time.

I would also like to add an RSS feed, and a suggested article feature that appears at the bottom of the post detail page.

Thanks for reading, hopefully you found this article useful. If you use a similar setup or if you give this a go yourself let me know on Twitter @CodingWithStef or in the comments below!

How I Deploy My Laravel Website With Envoy

Stefan Ashwell — Thu, 07 Jan 2021 21:56:45 +0000

So you‘ve built the perfect website, poured hours of time and effort making it perfect.

You’ve tested it in as many browsers and on as many devices you possibly can.

It’s finally ready - it’s time to deploy your website and show the world.

Luckily, Laravel is there for you - as it always is - with Envoy.

In this article I show you how I deploy my own website using Laravel Envoy, so you can do the same with yours.

What is Laravel Envoy?

Envoy is your new friend that will log in to your server for you and run any tasks you want it to.

By creating a single blade file, you can get Envoy to deploy your site at the run of a single command.

Let’s walk through how…

Setting Up

Before we begin, you need to have a web server set up and ready to go. Setting up a server ready to host your production site is out of the scope of this article, I’d recommend this article by Digital Ocean to get started.

You will need to be able to log in to your server via ssh. If you can log in from your machine via the command line, Envoy will be able to do its thing.

Once you’re set up, install Envoy with the following command:

composer require laravel/envoy --dev

Creating Your Envoy File

The Envoy file is where you tell Envoy what you want it to do.

In the root of your application, create a file named Envoy.blade.php.

The Envoy file will contain 2 parts. First, we set the server information.

@servers(['prod' => ['user@ip_address']])

This would be populated with your ssh user and ip address. Next, we can define any number of tasks. In our case well just create one called deploy.

@task('deploy', ['on' => 'prod'])

@endtask

Within our task, we list the commands we want Envoy to perform. Imagine you’ve logged in to the server yourself to deploy or update your site.

@task('deploy', ['on' => 'prod'])
    cd /path/to/codingwithstef.com
    git pull origin master
    composer install --optimize-autoloader --no-dev
    php artisan cache:clear
    php artisan view:cache
    php artisan optimize
@endtask

No Migrations?

My site isn't database driven, so there's no need for them to run in my case.

Here we are telling Envoy to:

Navigate to the website root directory
Git pull to get the latest code
Composer install in case any dependencies need to be updated
Clear our caches

composer install --optimize-autoloader --no-dev?

Adding the --optimize-autoloader and --no-dev flags optimises the autoloader for production and so is recommended for deployment.

Here's the full file:

@servers(['prod' => ['user@ip_address']])

@task('deploy', ['on' => 'prod'])
    cd /path/to/codingwithstef.com
    git pull origin master
    composer install --optimize-autoloader --no-dev
    php artisan cache:clear
    php artisan view:cache
    php artisan optimize
@endtask

That’s it, now we can run Envoy.

Running Laravel Envoy

You can use the following command to run Envoy.

php vendor/bin/envoy run deploy

You will see the commands being run in your command line so you can check everything’s been done correctly and also see any errors.

That’s it - how easy is that?

Taking it Further

For more complex set ups, you can run tasks on multiple servers, and even run them in parallel like so.

@servers(['server-1' => 'user@ip_address', 'server-2' => 'user@ip_address'])

@task('deploy', ['on' => ['server-1', 'server-2'], 'parallel' => true])
    cd /path/to/codingwithstef.com
    git pull origin master
    composer install --optimize-autoloader --no-dev
    php artisan cache:clear
    php artisan view:cache
    php artisan optimize
@endtask

You can even pass in arguments, for example you could tell it which branch to deploy.

@servers(['server-1' => 'user@ip_address', 'server-2' => 'user@ip_address'])

@task('deploy', ['on' => ['server-1', 'server-2'], 'parallel' => true])
    cd /path/to/codingwithstef.com
    git pull origin {{ $branch }}
    composer install --optimize-autoloader --no-dev
    php artisan cache:clear
    php artisan view:cache
    php artisan optimize
@endtask

php vendor/bin/envoy run deploy --branch=master

To read further, check out the Envoy documentation here.

Thanks for reading, hopefully you found this article useful. Having this in place on my site makes life so easy updating things!

As always, if you have any feedback or just want to chat about code, drop me a comment below.

Using Observers in Laravel to perform actions on model state change and clean up your code

Stefan Ashwell — Tue, 05 Jan 2021 11:16:44 +0000

Quite often you will need to perform actions when a model is created or changed.

Say you have a Posts model, you might want to send notifications of the new post to subscribers, or you might want to notify an admin every time a post is edited.

Whatever the situation, it’s automatic for us to put these actions in the controller that handles this creation or edit - after all, the controller is responsible for that action right?

That’s where observers can step in, to clean up your controller code and ensure these actions are performed however a model is updated.

What is an Observer?

Observers are classes that contain methods that are triggered when a models state changes. Under the hood, Laravel triggers events that observers can listen to.

Observers can perform actions on create, update, delete, restored and forceDelete.

When do Restored and forceDelete trigger?

These events are triggered on models that are using Soft Deletes, when either restoring or force deleting. Read more about soft deleting.

The idea is that whenever one of these actions is performed on a model - regardless of where or how - your actions are performed.

Think about this example:

You have a Users model, and in your application users can update their own information. Admins can also update a user's information. These two updates will typically be performed by different controllers.

Add to this equation an artisan command that updates users in bulk somehow, or there may be a scheduled task that updates users information.

In all of these situations, there could be additional actions to perform other than the update itself - such as notifying the user of the change, or logging the change for admin purposes.

It doesn’t make sense to have this duplication of code - if you wanted to change how these actions or fix a bug you’d have to do it 4 times.

That’s the perfect use case for an observer. It will listen for the change and perform actions every time.

Creating an Observer

Now you’re saying “less waffle Stef, how do I do this?”

Well, here we go. There’s an artisan command to generate an Observer:

php artisan make:observer UserObserver --model=User

This will create the class in an Observers directory, and if you open up that new class you’ll see the following boilerplate:

<?php

namespace App\Observers;

use App\Models\User;

class UserObserver
{
    public function created(User $user)
    {
        //
    }

    public function updated(User $user)
    {
        //
    }

    public function deleted(User $user)
    {
        //
    }

    public function restored(User $user)
    {
        //
    }

    public function forceDeleted(User $user)
    {
        //
    }
}

As you can see, there’s a method for create, update, delete, restored and forceDelete.

These methods accept the model as a parameter.

And quite simply, you can go ahead and perform whatever action you need to in these methods!

Here’s an example where we send a notification on update:

use App\Notifications\UserUpdated;

...

public function updated(User $user)
{
    $user->notify(new UserUpdated($user));
}

Simple right?

Registering Observers

There’s one final thing to do to get Laravel to use our Observer - we need to register it.

To do this we add the following to the boot method of our App\Providers\EventServiceProvider service provider:

use App\Models\User;
use App\Observers\UserObserver;

...

public function boot()
{
    User::observe(UserObserver::class);
}

Now, Laravel with use our Observer methods.

Skipping Observers

Observers are great, but there might be situations where you want to not have them run.

It could be that the scheduled task we mentioned before is just doing some clean up so the user doesn’t need to be notified every time.

In that case, you can use the saveQuietly method instead, for example:

$user->saveQuietly();

Observers: Done

And there you have it, Observers give you a nice clean way to react to model changes and perform actions in one place rather than duplicating code.

If you have any questions about Observers or Laravel in general, or any feedback about this article, drop me a comment below - I’m always happy to chat about code!

Until next time, happy coding.