By implementing the withDefault() method, you ensure your application returns a default model when a related model is absent. This prevents errors and allows you to define default attribute values for the related model.

Practical Example

Imagine you have a Post model linked to an Author model. Without default models, attempting to access the author of a post with no associated author leads to an error:

$post = Post::find(1);
echo $post->author->name; // Error if author is missing

Using withDefault(), you can handle this situation more effectively:

public function author()
{
    return $this->belongsTo(Author::class)->withDefault();
}

Now, if the author is missing, an empty Author model is returned instead of an error. Additionally, you can specify default attribute values:

public function author()
{
    return $this->belongsTo(Author::class)->withDefault([
        'name' => 'Guest Author',
    ]);
}

This way, if an author is not set, your application will use "Guest Author" as the default name, ensuring a seamless user experience.

Benefits of Using Default Models

1. Error Prevention: Avoid runtime errors due to missing related models.

2. Improved User Experience: Provide meaningful default values, ensuring your application remains informative and user-friendly even when data is incomplete.

3. Cleaner Code: Simplify your view logic by eliminating the need for null checks every time you access related models.

Terraform is an open-source infrastructure as code software tool created by HashiCorp. It allows users to define and provision a datacenter infrastructure using a high-level configuration language known as HashiCorp Configuration Language (HCL), or optionally JSON.

DigitalOcean is a cloud infrastructure provider that offers cloud services to help deploy modern apps. It's known for its simplicity and being developer-friendly.

Combining Terraform with DigitalOcean can significantly streamline the process of deploying and managing cloud infrastructure.

Prerequisites

1. Basic Knowledge of Cloud Computing: A fundamental understanding of cloud computing concepts is beneficial.

2. DigitalOcean Account: You'll need an active DigitalOcean account. If you don't have one, you can sign up at DigitalOcean.

3. Terraform Installed: Ensure you have Terraform installed on your machine. If not, you can download it from the Terraform website.

Step 1: Setting Up Terraform

After installing Terraform, the first step is to write a configuration file (.tf file) that describes the infrastructure you want to manage.

1. Initialize a New Terraform Directory: Create a new directory for your Terraform configuration and initialize it using the terraform init command. This command prepares your directory for Terraform operations.

2. Write Your Terraform Configuration: In your Terraform directory, create a new file named main.tf. This file will define your DigitalOcean infrastructure using HCL.

Step 2: Configuring DigitalOcean Provider

Terraform uses providers to interact with cloud service providers. For DigitalOcean, you need to configure the DigitalOcean provider in your main.tf file.

1. Provider Configuration: Include the DigitalOcean provider and your DigitalOcean API token (you can generate this token in your DigitalOcean dashboard) in your configuration. This step allows Terraform to authenticate with DigitalOcean on your behalf.

    provider "digitalocean" {
      token = "your_digitalocean_api_token"
    }
   

2. Define Resources: Define the resources (like droplets, load balancers, etc.) you want to create. For example, to create a droplet:

    resource "digitalocean_droplet" "web" {
      image = "ubuntu-20-04-x64"
      name = "web-server"
      region = "nyc3"
      size = "s-1vcpu-1gb"
    }
   

Step 3: Deploying Infrastructure

1. Plan Your Deployment: Run terraform plan to review the changes Terraform will make to your infrastructure.

2. Apply the Configuration: Execute terraform apply to deploy the resources as defined in your configuration file.

Step 4: Managing and Updating Your Infrastructure

• Modifying Resources: Update your .tf files to modify your resources and run terraform apply again.

• Monitoring Changes: Terraform tracks the state of your managed infrastructure and configurations.

Step 5: Destroying Infrastructure

When you no longer need the infrastructure, you can destroy it to prevent further charges. Run terraform destroy to remove all resources managed by your Terraform configuration.

Conclusion

Terraform is a powerful tool for managing infrastructure as code, particularly when combined with a cloud provider like DigitalOcean. It offers a reproducible and efficient way to manage cloud resources, significantly simplifying the process of infrastructure deployment and management.

Getting started with Terraform on DigitalOcean might seem daunting at first, but with the right steps, it becomes a straightforward and rewarding process. Happy coding and managing your cloud infrastructure!

What are Faker Factories?

Faker is a Python library that generates fake data such as names, addresses, emails, and more. Faker factories take this a step further by allowing you to create custom classes to generate complex, interconnected sets of data. This is particularly useful for creating realistic datasets for testing purposes.

Generating Users

Let's start with creating a Faker factory for generating user data. First, make sure to install the Faker library:

pip install faker

Now, let's create a simple user factory:

from faker import Faker

fake = Faker()

class UserFactory:
    @staticmethod
    def create_user():
        return {
            'username': fake.user_name(),
            'email': fake.email(),
            'full_name': fake.name(),
            'password': fake.password(),
        }

# Example usage:
user_data = UserFactory.create_user()
print(user_data)

We define a UserFactory class with a static method create_user. This method is responsible for generating a dictionary representing user data. The dictionary contains keys such as 'username', 'email', 'full_name', and 'password', and the corresponding values are generated using various Faker methods (fake.user_name(), fake.email(), etc.).

Then we create an instance of the UserFactory class (user_factory) and use it to generate user data by calling the create_user method. The resulting user_data dictionary is then printed to the console.

Example 1 demonstrates the creation of a simple Faker factory (UserFactory) that generates fake user data using the Faker library's methods for generating names, emails, and passwords. The factory pattern allows for easy reuse and extension, making it a convenient approach for generating consistent and diverse sets of data in testing scenarios.

Generating Products

Now, let's extend our use of Faker factories to generate product data. We'll create a ProductFactory:

class ProductFactory:
    @staticmethod
    def create_product():
        return {
            'product_name': fake.word(),
            'price': fake.random_int(min=10, max=100),
            'description': fake.text(),
        }

# Example usage:
product_data = ProductFactory.create_product()
print(product_data)

Example 2 demonstrates the creation of another Faker factory (ProductFactory) specifically tailored for generating fake product data. The generated data includes a product name, a random price within a specified range, and a description.

Combining orders for Products and Users

Now, let's tie everything together by creating a factory to generate orders. Each order will include a user and a product:

class OrderFactory:
    @staticmethod
    def create_order(user_factory, product_factory):
        user_data = user_factory.create_user()
        product_data = product_factory.create_product()
        return {
            'order_id': fake.uuid4(),
            'user': user_data,
            'product': product_data,
            'quantity': fake.random_int(min=1, max=10),
        }

# Example usage:
user_factory = UserFactory()
product_factory = ProductFactory()
order_data = OrderFactory.create_order(user_factory, product_factory)
print(order_data)

We define an OrderFactory class with a static method create_order. This method takes instances of user_factory and product_factory as parameters. It then generates an order, where the order ID is a UUID, and the user and product details are generated using the respective factories. Additionally, a random quantity is assigned to the order.

We create instances of UserFactory and ProductFactory. Then, we use these factories as arguments to create an order using the OrderFactory. The resulting order_data dictionary is printed to the console.

The OrderFactory not only generates order-specific information but also leverages the UserFactory and ProductFactory to create realistic user and product data for the order. This showcases the power of Faker factories in creating complex and interconnected datasets for testing scenarios.

Conclusion

Faker factories in Python offer a powerful way to generate realistic and interconnected datasets for testing purposes. By leveraging the flexibility of Faker and custom factories, you can efficiently create diverse sets of data for your applications. Whether you're testing user authentication, product catalog functionality, or order processing systems, Faker factories are a valuable tool in your testing toolkit.

In a later article, we will discuss how to set up the relay server as a docker container.

Prerequisites

• A server or access to create a new server (if you are using DigitalOcean: Droplet)
• A Microsoft Exchange account. It might work with a free Outlook 365 account, but this article will be based on Microsoft Exchange which costs about $4 per month.
• Your Exchange email DNS has already been configured (You can send and receive emails on your domain)
• Access to your applications DNS settings
• Basic Linux and network skills (It’s mostly copy-paste)

Introduction

Sooner or later any web application must send out emails, however, ensuring the emails are not ending up in the recipient’s spam folder, server IP is blacklisted or other obstacles can either be expensive or time-consuming.

Some solutions offer an API to this where they handle the mail server part for a fee. A lot will have a free as well, however, you will then in both cases be sharing the outgoing IP with many other clients heavily increasing the risk of being assigned a blacklisted one.

The reality for CloudMonitor has been that the low-cost solutions couldn’t tackle our email problem and the higher-priced couldn’t be justified. Searching for other solutions we decided to set up a Postfix relay server that transports the queue to Microsoft Exchange. Some of the benefits of using Microsofts Exchange are:

• World-leading mail infrastructure
• Never blacklisted
• Cheap service

Cons could be:

• No dashboard or metrics
• No API

These cons are fine for now as tracking can still be done with Matomo .

Installing Postfix

Since we are not going to handle questions about spam or sender validity, the setup of Postfix will be straight forward.

MX Domain

Before you start you should know the domain of your MX record. You can look up your domain at MX Toolbox to see which hostname is set for it: https://mxtoolbox.com/SuperTool.aspx?action=mx:&run=toolpage

Configure application DNS

Open your Exchange dashboard at https://admin.microsoft.com/

Under domains click Add domain

Enter the domain name you want to add (The domain of your email sender address).

Select that you will verify your domain by TXT-record.

Copy the given details to your DNS settings

Here shown how it will look in DigitalOcean

After your DNS has been added, simply choose to continue on how you want to connect your domain

Now you will be given your DNS details under MX Records, CNAME Records, and TXT Records. Insert those in your DNS settings.

Your domain is now added to Microsoft Exchange.

Install Postfix

On a newly created Ubuntu server install Postfix:

apt install postfix
postconf -e relayhost=<MX-hostname>
postconf -e smtp_use_tls=yes
postconf -e mynetworks=0.0.0.0/0

You must change MX-hostname with your own, but that’s it.

Make sure only you have access to the server, by, for example, restricting all incoming connections to your web server, or at minimum port 25.

Configure Microsoft Exchange

This step requires you to have a paid Exchange plan from Microsoft. It might work with the free Outlook mailbox too, but we haven’t tested it.

First go to your Exchange control panel: https://admin.exchange.microsoft.com/

Find Connectors and click Add a connector

Choose Your organization’s email server

Name your integration, we choose the name of the application

Choose Verify by IP and enter the IP of your relay server.

Click Create. Now the Exchange setup is done.

This post was originally posted on https://cloudmonitor.dk/setup-postfix-relay-server-with-microsoft-exchange-email/

The SaaS Problem

You are building a SaaS and each customer can add users, but users can only be added once, hence we want unique emails. However, the email must not be unique for all customers therefore we have to make this rule: For each unique customer id, all emails must be unique.

Use the Rule-class

The problem is that you can no longer use the basic unique:email rule anymore as this would block other customers from inviting that user.

The solution is to implement Laravels Rule-class.

return [
    'email' => Rule::unique('users', 'email')->where(function($query) {
        $query->where('customer_id', User::findOrFail($this->user)->customer_id)
            ->where('id', '<>', $this->user);
    }),
];

Syntax Explained

The concept here, as said, is to ensure the email is only unique across that customer's users. Let's look at the syntax:

return [
    // Tell Laravel which column it looks to be unique. Typically the same as on the left side
    'email' => Rule::unique($table, $column)->where(function($query) {
        // Add the extra criteria column, filtering the lookup to only those belonging to the same customer as the current user is
        $query->where($filterColumnCriteria, User::findOrFail($this->user)->{$filterColumnCriteria})
            // Last, skip the user being update avoiding error because it finds itself
            ->where('id', '<>', $this->user);
    }),
];

Implementation

The round up in a sample Request file:

<?php

namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;

class User extends FormRequest
{
    /**
     * Determine if the user is authorized to make this request.
     *
     * @return bool
     */
    public function authorize()
    {
        return true;
    }

    /**
     * Get the validation rules that apply to the request.
     *
     * @return array
     */
    public function rules()
    {
        return [
            'email' => Rule::unique('users', 'email')->where(function($query) {
                $query->where('customer_id', User::findOrFail($this->user)->customer_id)
                    ->where('id', '<>', $this->user);
            }),
        ];
    }
}

To keep things streamlined with WordPress, I had to implement this hack the other day, where I wanted to disable tag links on just 1 page.

Instead of fiddling with a new plugin, I found it easier, in this case, to disable the link in the template engine with pure CSS.

The magic to remove the link feature lies in pointer-events while the rest ensures it doesn't look like one.

a.disabled {
  pointer-events: none;      
  text-decoration: none;
  cursor: default;  
  text-decoration: none;
}

The semantics might be up for discussion, but the performance is possibly better than using Javascript.

This approach is available to all major browsers: CSS pointer-events (for HTML)

The reasons are such as the quality of your product won't be as good, the code might even be a mess. You might also have heard other reasons like lack of flexibility and hard to debug.

Why I Chose To Try a GUI Tool

I support all these reasons and I still believe they are true to some extend. However, as I have moved forward in my life and career along the road I have also learned that the real world is unfortunately not only a matter of quality. Sometimes we need to prototype fast, to test if an idea has its right to exist or it was just good on the planning board.

This doesn't mean quantity over quality, but it means that the old concept of re-factoring is indeed very valid here. You should prototype fast, GUI tools are perfectly fine here, as this is not the time in your project where your fiddle with 1 or 2px to the left, but rather focus on first releases.

My Experience Using A UI Tool

As your product grows, you will most likely realise that the GUI tool had its limits. This is why refactoring should always be in mind. Don't build your prototype on a closed platform where all your data might be stuck behind another company's proprietary wall.

Instead build with a tool that allows you for fast progress. Later on, if you have success, you build your custom solution and migrate the data. By this time you are also aware of what you need to do custom made.

Blogging Example

An example could be blogging. Hashnode is a great tool and platform to get started fast. When you have (for example) 100,000 daily visitors from not within the Hashnode community, you might start considering if you should build your own platform.

I chose to write my thoughts, after I saw the similar topic here: Why it’s perfectly OK to use no-code tools as a developer

It can also be used to perform various maintenance tasks to easen administration. You can think of Windows Update that runs in the background.

Cron

If you, like most people, are running Laravel on Linux, ie Ubuntu, it's important to understand the basics of cron in order to understand how task scheduling works.

A brief summary of the terminology

Cron job

A scheduled task in cron is called a cron job.

Crontab

All your cron jobs are stored in a table this is shortened to crontab (cron table).

On Linux you can edit the table with cron -e or list the entries with cron -l.

Syntax and interval

The syntax for a cron job in the crontab is:

Interval Command

The interval is defined by 5 numbers:

• Minute
• Hour
• Day of month
• Month
• Day of week

Asterix (*) is used to define an any paramater. If you want to run a command every minute it's simply: * * * * * command

I will not go further into the intervals, but you can generate your own at sites like https://crontab-generator.org/

Laravel task scheduling

It's important to understand the concepts of cron as Laravels task scheduling is tightly coupled to it. For example look at the first method described in the documentation:

->cron('* * * * *');

The rest of the methods are basically syntactic sugar to help you maintain more a readable code.

Laravels task scheduling is in fact not scheduling in itself. It's constructed so you run a cronjob every minute against Laravel which then checks its internal table to see if any commands are due to execution. This is important to know, if you want to investigate why your scheduled tasks are not running, it might be the cronjob is missing or not working.

Laravel cronjob

The cronjob for Laravel is (crontab -e):

* * * * * cd /path-to-your-project && php artisan schedule:run >> /dev/null 2>&1

Cronjob permissions

You should add this cronjob in www-data (or what other name your web user has) in order to retain proper permission on files.

Use cases

Caching

As mentioned earlier caching is a situation where you can benefit from background tasks. An example from my own experience is where we have a pivot table. A pivot table is a useful tool if your clients needs to lookup data in many different ways with filters, customised output and so on. However, since the data come from across the whole application and the tables have several thousands of records, it's not a few seconds job to collect the data.

Instead we have set up task scheduling to cache this whole output every 15th minute (->everyFifteenMinutes();) so with a slight delay the users can load the pivot table in a few seconds instead of minutes.

Maintenance

Another useful situation is when you want to perform maintenance jobs, but don't want to have to click a button every day to execute the maintenance script.

You might have implemented GDPR and added a feature where users have the right to be forgotten. You might also leave a door open, so that they can cancel the process within 14 days. This means when they request deletion you mark them with a timestamp deletion_request_at, after 14 days, if not nulled, they will be removed.

You could set a task to run every midnight (->daily();) to check if any such users has passed 14 days.

Debug task scheduling

A common issue with scheduled tasks, since they are performed in the background, is that it can be difficult to monitor if they are running at all and when they are failing it can be even more difficult to understand what went wrong.

For that reason I created a Task feature in CloudMonitor that will not just monitor if your scheduled tasks are running as expected, but will also show you the output so you know what exactly went wrong.

A log history allows you further to learn if it's the same error that is happening every time or they differ. It could be sometimes a remote service don't respond and other times your memory is exhausted, etc.

CloudMonitor.dk – Free Laravel Maintenance- and Bug Management

In modern software architecture it's often necessary to communicate between applications a common way to do this is by using an API. APIs (Application Programming Interface) are interfaces optimised for applications rather than humans as their purpose is to transfer data from either backend to frontend, for example PHP to JavaScript or from one application to another.

This post I will focus on the second case, between 2 applications. When doing so, you transfer data across the internet and must therefore, for a numerous reasons, retain more focus on security, such as man-in-the-middle-attacks, spoofing and so on. In other words you must make sure both server and client can identify and validate each other and data between is encrypted.

Implementation

The idea is that you send some unencrypted data as headers, this could be:

• Timestamp
• Version
• Token
• Signature

Along the headers the body contains an encrypted message that needs all or some of the headers to be decrypted with a secret.

Timestamp

The time the message was sent, this can be used to monitor transfer delay but also as a parameter to the signature.

Version

Tells the server which version the client is on, you can both use this data to know how to handle the incoming request on the server, but also to know when a version is not used anymore or which clients to upgrade.

Token

The token, also often known as key, tells the server which client or configuration, is the author to lookup for the secret stored on the server. It could be as simple as an user id.

Signature

The signature is generated with a set set of the parameters to create a unique key that the server can use to validate the authenticity of the sender.

Secret

The secret is very important here, it's the key that should only be known by host and client and never shared and also easy to regenerate in case it was mistakenly shared.

Implementation in Laravel

Signature

First the client should generate the signature, let's assume we have these variables we are going to work with:

$timestamp = time();
$version = '1.0.0';
$token = 'my_key';
$secret = 'my_secret';

To validate the signature, both server and client must have the same method in order to parse the parameters to the same result. A method to create a signature using hash_hmac could be:

function createSignature(int $timestamp, string $secret): string
{
    return hash_hmac('sha256', $timestamp . $secret);
}

The advantage here using a hash algorithm is that it's not designed to be decrypted again. We are not interested in the actual content of the plain text, just if we can match the string on both servers.

The message

Now we have the following variables:

$timestamp = time();
$version = '1.0.0';
$token = 'my_key';
$secret = 'my_secret';
$signature = createSignature($timestamp, $secret);

Unlike the signature, we want to be able to decrypt the content of the message. Since this guide is based on Laravel I benefit from the build in Encryption class Illuminate\Encryption\Encrypter.

use Illuminate\Encryption\Encrypter;

function encrypt(string $secret, string $message): string
{
    $encrypter = new Encrypter($secret, 'AES-128-CBC');

    return $encrypter->encrypt($message);
}

Here we use the secret in order to encrypt the content of our message, if you have an array you could use json_encode/json_decode.

The secret

This illustrates why it's important to keep the secret secured as it's the magic key to break into your encrypted system.

Sending data

When using Laravel I will recommend using Guzzle as it's straight forward easy to work with. Here's how you can do it:

function send(string $message, string $key, string $secret, string $url) {
    $client = new Client();
    $response = null;
    $timestamp = time();
    $version = '1.0.0';

    try {
        $response = $client->request(
            'POST',
            $url,
            [
                'headers' => [
                    'timestamp' => $timestamp,
                    'version' => $version,
                    'token' => $key,
                    'signature' => createSignature($timestamp, $secret),
                ],
                'form_params' => [
                    'data' =>encrypt($secret, $message)
                ]
            ]
        );
    } catch (Exception $e) {
        throw $e;
    }

    return $response;
}

CloudMonitor.dk – Free Laravel Maintenance- and Bug Management

The tech stack

The stack I have used to create this project is:

• DigitalOcean
• Laravel 7
• Vue 2
• MySQL
• Bootstrap

These are all applications, platforms and frameworks I have been using extensively for years, thus I have a vast experience. However there was obstacles on the way and this was also intended. I wanted to challenge myself and to both learn new techniques but also show off what I can do.

DigitalOcean

Is used to tackle all the infrastructure, from a Ubuntu server (Droplet) with Apache2, firewall, nameservers, cloud backup (Spaces) and managed database (MySQL). The great thing about thing about DigitalOcean is that it's very cost effective to get started as a startup. The only peak in my setup is the managed database, but that could easily be hosted on another Droplet (self-managed) or even the same Droplet as your Apache2/webhost, though the last option is not recommended for production.

For instance if you want to setup similar to mine with webserver, database and backup:

What I love about DigitalOcean is their straight forward, and cheap, prices, where AWS has a lot of running costs that can be hard to calculate. DigitalOcean for instance offers free nameservers, where that has a small price for AWS.

If you want to try DigitalOcean you can use my link: DigitalOcean - it's an offer for both us:

Everyone you refer gets $100 in credit over 60 days. Once they’ve spent $25 with us, you'll get $25.

Laravel, Vue and Bootstrap

As this is a tool to help Laravel, it only made sense, that the tool itself is written in Laravel. The idea of the package for you install in your application to communicate with the server is to work out of the box, with a very minimum of configuration.

Where Laravel is the backend serverside language, written in PHP, serving all the logic in the background, Vue is a Javascript framework and therefor handles all the dynamic content in the interface.

The styling and layout is handled by Bootstrap which allows for a streamlined standardised layout. A great tool I have found along the way is bootstrap.build where you can style all its components online and refer to a CDN, before you download the modified files, this better ensures for strictly following Bootstraps guidelines while customising the look.

Underlying techniques

There are many underlying techniques I have been tackling in this project, so I will just cover a few here.

Package development

Key / secret

As the platforms purpose is reporting errors on other applications, I naturally had to create a client package that can report these incidents. So it was not just one, the main, application, but two. This would not work without some sort of communication between them and since fragments of code is to be sent in order for better debugging I felt it was needed to encrypt this communication. I ended up using a key/secret approach. The idea is the whole message on the client is encrypted using the secret, which the server also stores and is not transmitted at all. The key is sent along the encrypted message to tell the server which key to lookup to find the unlock secret. The server keeps a throttle limit so too many failed requests will result in a block to avoid brute force.

Testing

One of the biggest issues I had for a long time before I found a solution was to test the client package. One thing is to develop a client for your main application, but often the errors happens when something goes wrong with the communication to the server. I implemented a few steps to tackle that:

• Versioning, ensuring that client and server a tracking on the same versions, and if breaking changes must be added, the server can handle requests based on the clients version.
• Communication, I added methods for sending test incidents through the system, so I could force an error to see everything is working before releasing either the server or the client update including debugging information both back to the client and stored on the server.

CloudMonitor.dk

I have been working professionally fulltime with Laravel for 6 years now and wanted to create a platform that gives me better insights to running applications. I don't believe these utilities should come as a part of an application but rather an external tool that by time can generate its own useful data for further development.

Therefor I used my knowledge and started on a project I call CloudMonitor. As for now I have implemented an outline of what I feel is core essential features for its purpose:

• Bug tracking
• Task
• Backup
• Uptime

All this I have chosen to provide for free. The project is still, as many projects, in development and you have a great opportunity take part in the future as the roadmap is flexible enough for inputs.

Bug tracking

This works as any bug tracker you know (Sentry, Bugsnag). You can see a snippet of what is going wrong, a stack trace and query log. Also a collection of events to see how often it occurs and maybe even proactively contact clients to follow up on an issue before they face it too many times with frustrations.

Tasks

Laravel features scheduled jobs or tasks, which is a very useful tool, however it lacks of good insights and this is what's shown here. Quickly see if the task failed, missing or succeeded but also watch the output in the terminal which is especially useful when it fails to know what failed – it might not always result in an exception.

Backup

For now it's build upon Spatie Backup and utilises events from there to track if backups are running and healthy, but also if the cleanup is running.

Uptime

Checking every 10 minutes to check if the domain is still accessible and if HTTPS that the certificate is still valid.

Overall

Everything is done with logs in mind, so you can build statistics on your applications performance and as an extra feature you can add what's called 'Installations', which is collecting data from 2 or more servers running the same software. This is useful if you setup up the same codebase for 2 clients on different servers, but it's not a SaaS, since a bug in one installation would also be a bug in the other and collection of events might be useful across both.

CloudMonitor.dk

I will cover the basic use of Laravel Blade with Bootstrap for a signed in user, you should get the idea afterwards if you wish to create a layout for the landing page as well.

This article is written with Laravel 7 in mind.

Setup

After you setup your initial Laravel you should use Laravel/UI to install Bootstrap:

1. Install Laravel/UI: composer require laravel/ui
2. Prepare Bootstrap: php artisan ui bootstrap
3. Install assets: npm install

Structure and core layout

Worth noting about Laravel Blade

Section names

You can only use a section name once in a structure, this means you are going to have a conflict if you 2 templates uses the same section name:

// Template 1
@yield('content')

// Template2
@extends('Template1')
@section('content')
  @yield('content')
@endsection

This is prone to errors !

Ending sections

A section can be ended by either @stop or @endsection. Which you choose is up to you, but in my opinion @endsection gives you a more readable template.

Structure

I like to keep my structure as closely related to the one suggested from Laravel, this ensures it's easier for me in the future to go back and modify the code, but also easier for participants to understand my code. Therefor all Blade templates are stored in /resources/views.

Layout specific templates will be put inside the subdirectory layout. Within that I like to keep a subfolder called parts, this contains menu, footer, header and other commonly used parts that should be accessible through the various layout templates.

Base

Within layout create a new file called base.blade.php. This is the base template for all templates – but only extended by layout templates.

<!DOCTYPE html>
<html lang="en">
    <head profile="http://www.w3.org/2005/10/profile">
        <meta charset="utf-8">
        <title>My site</title>
        <meta name="app-url" content="{{ url('/') }}">
        <meta name="viewport" content="width=device-width, initial-scale=1.0">
        <link href="{{ url(mix('css/app.css')) }}" rel="stylesheet">
    </head>
    <body>
        @yield('page')
        <script src="{{ url(mix('js/app.js')) }}"></script>
    </body>
</html>

Blank

Next create a file in layout called blank.blade.php, this will be the most basic layout. It may seem redundant not just to extend base, but this way we can keep a streamlined architecture and sometimes you might want to force ie a footer to even the minimal layout.

@extends('layout.base')

@section('page')
    @yield('content')
@endsection

Also, we ensured the section you later refer to is always content.

App

For the signed in user the there should be a layout that represents the app view. This will include:

• Navigation
• Header
• App content area

@extends('layout.base')

@section('page')
    @include('layout.parts.navbar')

    <div class="container-fluid">
        <div class="row h-100 mt-3">
            <div class="col">
                @yield('content')
            </div>
        </div>
    </div>
@endsection

@include and @yield

We have worked with 2 different ways to work with external template files. The difference is in logic, or direction you might say, they are injected. @include is when the template working in knows which external template to inject, such as navigation. This is useful when you have parts of templates that are used in many templates but don't want to rewrite it.

@yield is when the template working in, doesn't know the content, this should be more seen as a variable placeholder for child templates to inject content into the parent. (@section).

Not covered here, but useful to add is a global handler for alert and info messages.

Navbar

For our navbar this should be stored in layouts.parts.navbar. As the navbar isn't going to have any sub-elements I will just use the default from Bootstrap:

<nav class="navbar navbar-expand-lg navbar-light bg-light">
  <a class="navbar-brand" href="#">Navbar</a>
  <button class="navbar-toggler" type="button" data-toggle="collapse" data-target="#navbarNavAltMarkup" aria-controls="navbarNavAltMarkup" aria-expanded="false" aria-label="Toggle navigation">
    <span class="navbar-toggler-icon"></span>
  </button>
  <div class="collapse navbar-collapse" id="navbarNavAltMarkup">
    <div class="navbar-nav">
      <a class="nav-item nav-link active" href="#">Home <span class="sr-only">(current)</span></a>
      <a class="nav-item nav-link" href="#">Features</a>
    </div>
  </div>
</nav>

Using the layout

@extends

Now building our content page we can benefit from the layout templates. @extends allows to inherit a parent template sort of how extends works for a class in PHP. I like to put @extends at the top of my blade files.

Create the file /resources/views/content.blade.php with the following content:

@extends('layouts.app')

@section

Remember we used @yield in the layouts file? This is referred to as sections in child templates. This means we create a section in the child, which is injected at the yield point in the parent template.

You should avoid ending up with 2 names that are the same, unless it's unlikely the templates are used together such as for the different layouts

Make your content site look like this:

@extends('layouts.app')

@section('content')
    <div class="row">
        <div class="col">
             <div class="card">
                 <div class="card-body">
                     My content goes here, both plain text, HTML and Blade syntax.
                 </div>
             </div>
        </div>
    </div>
@endsection

A problem for me though was that if I seed users with a password it would mean I either have to store the passwords in the .env-file or commit them to git.

So instead I researched and found a way to generate a password reset token and send the notifications, so now when I seed users will receive a link to create a secret password.

This method is mainly useful if you are 1 developer as you don't want to let the whole team know that you have just reset the database on your local machine.

Here is the basic use of UsersTableSeeder.php which you can extend. Please note that I use the built ind authentication features of Laravel and have set up Mailgun in order to receive emails.

<?php

use App\User;
use Carbon\Carbon;
use Illuminate\Auth\Notifications\ResetPassword as ResetPasswordNotification;
use Illuminate\Database\Seeder;
use Illuminate\Support\Facades\Hash;
use Illuminate\Support\Str;
use Illuminate\Auth\Passwords\PasswordBroker;

class UsersTableSeeder extends Seeder
{
    /**
     * Run the database seeds.
     *
     * @return void
     */
    public function run()
    {
        $user = User::firstOrCreate([
            'name' => 'John D.', // Your display name
            'email' => 'mail@domain.tld', // Your email address
            'password' => Hash::make(Str::random(32)), // Password can't be empty so I generate a random non-known password.
            'email_verified_at' => Carbon::now(), // I don't want to also have to verify the account, so I let it be verified per default.
        ]);

        $user->notify(new ResetPasswordNotification(app(PasswordBroker::class)->createToken($user))); // This generates a token and sends the email
    }
}

Yesterday I discovered webhook.site which generates a unique URL for you and let you call that so you can see the calls in their interface and even heads and such.

The service doesn't require any registration and the basic service is free to use and should serve most needs.

How to use it

1. Go to https://webhook.site/
2. Copy the URL marked in grey
3. Open the URL and watch in the main tab how the requests are displayed instantly - don't worry, the hook URL will always be a blank page.

It's not my product, but this tool is a great help to me, I hope it can help somebody else too :-)

https://webhook.site/

From the authors blog he has posted an article about what webhooks are: What is a webhook?

Until now I have managed to read around it, but it still annoyed me.

Finally today I found the solution in this thread: https://laracasts.com/discuss/channels/laravel/php-artisan-not-working-4?page=1#reply=543852

Solution

As Nakov says, you must have this package in your project to make it look correct again:

composer require symfony/console:4.3.4

For security reasons, having files or folders with write and execute permission is never an optimal solution while working with a website, but also as for risk management such as backup, it’s a better choice to use a storage service. Fortunately this is very easy and cheap to integrate into a Laravel project.

The naming Amazon is used for simplicity here, although the actual name is AWS (Amazon Web Services) which is a subsidiary of Amazon.

Storage Service

Storage services or cloud storage as it is also called dates back to the beginning of the internet in mid-90s, but 10 years later when Amazon introduced their Simple Storage Service (S3) it became a lot easier to benefit from as they provide a simple API and tools to make scaling easy.

Other companies have since started to compete with Amazon. My favourite is DigitalOcean who has adapted the same API as Amazon uses. Whilst not being the only competitor with this feature, I believe DigitalOcean is a great platform for Laravel projects.

Amazon S3

Since DigitalOcean uses the same API as Amazon all the configurations from this article will work for both. You will also realise that the settings in Laravel are referred to as S3. For this reason it’s rather simple to later migrate from DigitalOcean to AWS if you keep the endpoint as a constant in your .env for instance.

Read more about S3 at Amazon: https://aws.amazon.com/s3/

DigitalOcean Spaces

The file storage solution, Spaces, from DigitalOcean works with an API as with Amazon. As mentioned earlier the API is the exact same, although with fewer advanced features.

The advantage of DigitalOcean is that you pay a fixed price per month, starting from $5, while at Amazon prices are fluid based on storage usage, data transfer and so on. It might be cheaper at first using Amazon, but the price changes dynamically for that reason. Larger projects with bigger budgets might have less overhead from Amazon though.

The fixed price includes a range of usage while exceeding this you will be charged, but it’s unlikely that you will exceed.

Read more about DigitalOcean Spaces: https://www.digitalocean.com/products/spaces/

Configure Laravel

Making Laravel ready for a storage service is straight forward and well described in the documentation . I will give a brief description on how to get it running.

Since DigitalOcean utilises the Amazons API, you’ll have to install the AWS SDK in both cases

composer require league/flysystem-aws-s3-v3

Next you need to add a few lines to .env to configure your storage api.

# The secret generated from DigitalOcean API
AWS_ACCESS_KEY_ID=
# Key from DigitalOcean API
AWS_SECRET_ACCESS_KEY=
# Region ID for your Space (nyc2, sgp1, fra1, sfo2, ..)
AWS_DEFAULT_REGION=
# The unique name you chose for your Space
AWS_BUCKET=
# Full URL without name ({REGION}.digitaloceanspaces.com)
AWS_URL=
# Endpoint
AWS_ENDPOINT=digitaloceanspaces.com

You must make one minor change to your filesystem driver in config/filesystem.php by adding the endpoint parameter:

's3' => [
  ...
  'endpoint' => env('AWS_ENDPOINT'),
],

Now you can store files either per default to your cloud storage or when desired also locally.

Cloud as default

If you want to store everything on your cloud, the easiest is to set it as the default storage service in your .env:

FILESYSTEM_DRIVER=s3

Now you can access your cloud storage per default, without declaring a disk:

Storage::..

You can still use the local driver by specifying it:

Storage::disk('local')->..

Cloud as an option

If you rather want to use cloud as an optional feature and not default, you don’t have to do more. Instead you must refer to you the cloud disk when using it:

Storage::disk('cloud')->..

Documentation

For full a full list of features for the Storage class read more in the official documentation: https://laravel.com/docs/7.x/filesystem

Notes

Cross Origin Resource Sharing (CORS)

CORS are probably only relevant to you if you plan to use DigitalOceans CDN feature. In most cases if files are streamed through you application it’s unnecessary to make any changes to these settings.

A few links about CORS https://en.wikipedia.org/wiki/Cross-origin_resource_sharing https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

File listing

You should in most cases disable file listing. It won’t prevent your API and Laravel application to list files on your Space, but it will prevent others from directly typing the URL to your Space and browse the files. File listing can be changed in your Space’s settings:

Limits

There are a few limits to the Spaces, but these are unlikely to bother you if you have a small to a medium sized site. If you are facing the limits it’s most likely because you use Space as CDN without configuring it to be so. Read more about limits: https://www.digitalocean.com/docs/spaces/#limits

Packagist is the platform behind Composer acting as the library. When you are searching for a new package for your project, you are probably doing this through Google, which works perfectly fine and I do so as well. But in fact you could do an even more targeted search on Packagist.org.

The steps

But how does Packagist work? Let’s split it into the steps necessary when creating a package for others to install through Composer:

1. Developing the package itself
2. Hosting it on a git platform, Github will be the easiest
3. Submitting the repository to your Packagist account

This article will not be covering how to develop a package, if you are interested in that part I can recommend my article I wrote for Hashnode: Laravel Package – How to build and deploy

There you will also find a brief description of deployment, but that will be covered in more details here.

Push to Github

If you already know how to push your package to Github, you can skip this step.

First you must create your repository on you Github account https://github.com/new . Rememeber it must be public in order to work with Packagist.

As Github states you must initialize your repository on your computer and push the files to Github.

git init
git commit -m "initial draft"
git remote add origin git@github.com:<account>/<repository>.git
git push -u origin master

Submitting to Packagist

Navigate to Packagist and click Submit https://packagist.org/packages/submit and enter the URL of your repository

Click check and submit.

Failed to submit

If you are receiving errors concerning composer.json this means you have an invalidate or missing the file in the root of your repository. The base of composer.json should contain:

{
    "name": "MyName/repository",
    "authors": [
        {
            "name": "Firstname Lastname",
            "email": "email@address.com"
        }
    ],
    "require": {}
}

This can be created in your package with the command composer init and validated with composer valid.

Github webhook

The last step is to add a webhook to your Github repository in order for Packagist to be pinged every time you update your package.

Go to your repository’s Settings, then Webhooks and Add webhook

Remember to update your username in the Payload URL parameter.

Your unique Packagist token can be found at your profile: https://packagist.org/profile/

Your package can now be installed by others

composer require your-github-name/your-repository-name

Versioning

Packagist uses Git tags as version indicator. This means you could start your first tag as 1.0.0 then 1.0.1 and so on. Read more about semantic versioning at https://semver.org/

To add a tag and push the tags to your repository use the --tags parameter when you push

git tag 1.0.0
git push --tags

This can be a challenge in the beginning to keep up which version to tag. To list the tags used for a repository use the command without a value

git tag

A graphical tool such as SourceTree can also be useful when managing tags, but everything can be done from the command line, of course.

You are now set to share your packages with the world.

If you are interested in the article it can be found here https://emil.moe/2019/10/backup-laravel-easily-on-remote-server/

For this post I will share my final script for your convenience.

The script is

# YOUR VARIABLES
key=xxxxxxxxxxxxxxxxxxxx
secret=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
endpoint=xxxxx.digitaloceanspaces.com
bucket=my-unique-name
dbuser=root
dbpassword=secret
dbname=database

# MIGHT NOT NEED EDIT
file=db-backup.sql
dbhost=127.0.0.1

# STATIC VARIABLES
file=$(date "+%Y.%m.%d-%H.%M.%S").${file}
resource="/${bucket}/${file}"
contentType="application/sql"
dateValue=`date -R`
stringToSign="PUT\n\n${contentType}\n${dateValue}\n${resource}"
signature=`/bin/echo -en ${stringToSign} | openssl sha1 -hmac ${secret} -binary | base64`

# DUMP SQL
mysqldump --host=${dbhost} --user=${dbuser} --password=${dbpassword} ${dbname} > ~/${file}

# UPLOAD
curl -X PUT -T ~/${file} \
  -H "Host: ${bucket}.${endpoint}" \
  -H "Date: ${dateValue}" \
  -H "Content-Type: ${contentType}" \
  -H "Authorization: AWS ${key}:${signature}" \
  https://${bucket}.${endpoint}/${file}

# REMOVE FILE AFTER UPLOAD
rm ~/${file}
`

And should be schedules with a cronjob:

* */4 * * * sh ~/backup.sh >/dev/null 2>&1