While /dashboard is a sensible default for many SaaS applications, it isn't always what you need. Perhaps you are building an admin panel that lives at /panel, or maybe you are building a membership site or e-commerce store where the user should simply return to the homepage (/) after logging in.

If you dive into the official documentation, you might find yourself deep in bootstrap/app.php trying to customize the auth middleware logic. While that works, there is a much simpler configuration change that handles this in seconds.

The "Hard" Way: Middleware

Typically, the documentation guides developers to intercept the request within the bootstrap/app.php file to handle redirection for guests and authenticated users. This involves defining closures and logic that can clutter your bootstrap file if you only need a simple path change.

The "Easy" Way: Config Configuration

If your starter kit is powered by Laravel Fortify (which handles the backend authentication logic for kits like Jetstream), you don't need to touch your middleware or controllers. You can control this behavior directly from your configuration files.

Here is the one-line fix:

1. Navigate to config/fortify.php.
2. Locate the 'home' key (usually near the top of the file).
3. Change the value from RouteServiceProvider::HOME (or '/dashboard') to your desired path.

To redirect to the Homepage:

'home' => '/',

To redirect to a custom Admin Panel:

'home' => '/panel',

Why this works

Laravel Fortify uses this configuration value to determine where to send the user immediately after the authentication guard confirms their credentials. By changing it here, you ensure that the redirect is consistent across your application without having to write custom redirection logic in your controllers.

Don't overcomplicate your authentication flow. Before you start writing custom middleware logic in Laravel 12, check your config/fortify.php file. A simple string change is often all it takes to get your users exactly where they need to go.

Meetup was planned at 10 a.m. I reached Les Fascines, Vivéa Business Park fifteen minutes earlier. As I arrived in the parking lot, I started reading the signage to look for directions for Workshop17. Just then, I saw Bruno and Nathan, both walking towards the building. I waived at them and we talked while walking towards the entrance.

Ravish Dussaruth was the event host (for the day). He welcomed everyone and gave an introduction about the Laravel Moris community. He spoke about Laracon India which he attended earlier this month along with other co-organisers of Laravel Moris. He thanked the two sponsors of today's meetup, Viitorcloud and NativePHP.

Then, Ravish introduced today's first speaker, Percy Mamedy, who is also a co-organiser of Laravel Moris.

Percy spoke about the recent release of Laravel Starter Kits. He highlighted the features of the three default starter kits, React, Vue and Livewire. E.g the React starter kit comes with Inertia.js pre-configured, it's built using the shadcn/ui library, and comes with user authentication features, either using the built-in Laravel authentication (which most of us are familiar with) or WorkOS Authkit. I know nothing about WorkOS. Even Percy asked the attendees if anyone was familiar with WorkOS and could share thoughts on that but no one used it before.

Then, Percy did a quick demo of the starter kits, showing how easily and quickly one could adapt the layout with the different options available. Also, one could further customise the code if the default layout/style is not preferred.

Lastly, he mentioned that Laravel now allows the use of custom starter kits. Therefore, developers are not limited to starting a new project with the default Vue, React and Livewire starter kits, but one could pull a community based starter kit, say for example a Svelte starter kit and use it, one could build his/her own starter kit as well.

laravel new my-app --using=statamic/statamic

The above command creates a new Laravel project using the Statamic starter-kit. During the discussion, as Percy's presentation ended, someone asked that it would be nice if there is a location where all starter kits could be published. I found a GitHub project by Tony Lea which lists such starter kits. The one by Statamic seems to have garnered the most installs so far.

After Percy's presentation, Sanjivee Muthoora spoke about Viitorcloud.

He mentioned the participation of Viitorcloud at Laracon India and Laracon EU. He also shared information about the company, projects that they've delivered and some exciting projects that will be released soon.

I was the next speaker in line.

My presentation was titled, "deploying Laravel with FrankenPHP".

I started with a problem statement — at La Sentinelle, for years we struggled to host news content locally. Recently, thanks to cloud.mu, that has been possible. However, the Virtual Private Servers (VPS) do not provide us similar fast provisioning and auto-scaling features like those available from major cloud providers. In our quest to build something similar on top of the cloud.mu infra, we decided to experiment with Kubernetes — for future web projects.

I showed a few examples of Laravel based websites that we've developed at La Sentinelle, while mentioning which starter kit we used. Then, I mentioned the websites of the Cloud Native Chapter of Mauritius and meetup.mu created by Alex Bissessur, both sites run Laravel. Lastly, I mentioned the Developers Conference website, which also runs Laravel.

Next, I explained the process of containerising a Laravel application using a Containerfile which I jokingly said I prefer instead of the other one that starts with D.

Bruno, confirmed that podman recognises Containerfile and that I would not require the -f option to specify the filename, but instead I could simply use the dot . symbol. Meaning, I could run the podman command as follows to build the container image.

podman build -t 5plus:laravel .

Once the image was built, which took about 17 seconds, I pushed the image to the GitHub's container repository. Then, I open my Kubernetes deployment YAML file to update the image name, and finally I applied the deployment file. We waited a few minutes for Kubernetes to deploy a pod with the new image and when it was done, I tested the web page. It worked.

I answered a few questions related to Kubernetes. I missed Alex during the Q&A time, as his k8s knowledge was required to answer questions regarding monitoring of deployments and how to handle failed deployments. Alex could not make it to this month's meetup, but I'm sure in a future meetup, he will be able to assist anyone wishing to learn more about managing deployments.

The next presenter was remote — Sarthak Shrivastava from India. Sarthak is a Software Engineer at Pfizer and is the founder of Bitfumes.

Sarthak spoke about Vibe Coding. He gave a bit of background on conversing with AI. He explained about prompt engineering — not giving too many tasks in one prompt and try to break down the tasks into several prompts with concise instructions. He also mentioned that sometimes people personalise the AI by saying something like "you are a Laravel developer with 10 years of experience" but Sarthak advises to use "you have 10 years of programming experience" instead, in order to broaden the expertise area rather than keeping it within the scope of Laravel.

He did a demo using Cursor — the AI code editor that has been much in the news, since Vibe Coding has gone viral. It was a nice talk, we had a exchange of ideas on comparing Cursor with VS Code + GitHub Copilot.

We had lunch break after Sarthak's talk and demo.

The last talk was also remote, and a short one, by Simon Hamp, the creator of NativePHP — the cool stuff that allows you to build desktop and mobile applications using PHP. 🤯

Simon shared his motivation behind creating NativePHP. He explained how awesome things that can be done with it and invited us to try to build applications with NativePHP. He explained that the idea of putting a license for using NativePHP mobile is solely to generate revenue that can sustain the continuous development of the project. He also explained about the Early Access Program (EAP) for NativePHP mobile.

As we reached 1.30 p.m., it was almost time to end meetup. The last fifteen minutes was spent with a fast Q&A with some of the speakers that intervened, i.e Percy, Sarthak and myself, in a panel style. We tried our best to answer the questions. 🙏

The meetup was attended by about 15 people. It was time well-spent with the Laravel community of Mauritius.

It occurred with both the paginate() or simplePaginate() methods.

After a lot of unsuccessful search on the internet, I finally found the solution at the obvious place — Laravel Livewire official documentation.

The docs page for Livewire 3.x has a section for pagination. It mentions the default behaviours and how to change those. As per the docs, the default behaviour of the paginator is to scroll to the top of the page after every page change (which occurs when clicking the pagination buttons). In order to disable this behaviour, you should pass false to the scrollTo parameter of the links() method.

{{ $posts->links(data: ['scrollTo' => false]) }}

The docs provide more information about customising the paginator. Now that I know this exists, my Livewire tables in the future would be more customised. 😊

After many years, I participated in an event organised in collaboration with the University of Mauritius. Ten years ago, around this time of the year the Linux User Group of Mauritius and the UoM Computer Club (2013) organised a Linux Festival at the Paul Octave Wiehe Auditorium. Last Saturday's Google Developers Festival (DevFest) 2023, being held on the campus of the University of Mauritius, brought back memories of those days. It also reminded me that it's been a decade since I am actively contributing to the tech community. 🎊🤓

Some happy tears flow down the cheek. Sniff!

Okay, let's talk about DevFest 2023. DevFest is an annual tech conference organised globally by the Google Developer Groups (GDG) community. This year marked the 5th edition of DevFest Mauritius. It was hosted by GDG Mauritius and the University of Mauritius (UoM). The Google Student Developer Clubs of UoM, University of Technology, Polytechnics Mauritius and the African Leadership College helped in spreading the word.

Registration for the event was done through the GDG Mauritius chapter page on the Google Developer Groups Bevy platform, while information about the event, the agenda and the speakers was also available at devfest.mscc.mu.

We had 20 speakers from different tech backgrounds — web development, mobile application development and systems/cloud engineering.

My presentation was scheduled at 11:30 a.m. in the G2 room of the Faculty of Law & Management. I started the presentation sharp on time to be able to stay both on track and on time, as for the next 45 mins, I had planned a whole journey of writing code to deploying the same on a cluster of servers.

PHP is still relevant in 2023. It still powers a lot of websites on the Internet. Even Facebook started on PHP and later created the HipHop Virtual Machine (HHVM) to compile PHP source code to HipHop bytecode for faster execution and then they created the Hack programming language.

I started the presentation by talking about PHP.

If you are just starting with PHP development, I suggest that you closely follow the works of a PHP framework, like Laravel or Symfony. I use Laravel a lot — in fact most of my web related work is now on Laravel. During the presentation I mentioned how lexpress.mu moved from Drupal to Laravel.

My next slide had a few commands needed to create a Laravel project and to run it locally (assuming that PHP and composer are already installed on that machine).

Now, that we had a codebase and we made our desired modifications to the Laravel code, it was time that we thought about packaging it and shipping it to the cloud. The easy way — containers!

SUSE Base Container Image (SUSE BCI) enters the scene. We can of course find plenty of PHP based containers to ship the code, then why SUSE BCI? The short anwser is compliance. Very often if you are working for a big company, there are rules to use software that have enterprise support. SUSE BCIs are enterprise-ready container images based on the SUSE Linux Enterprise Server (SLES). One can purchase a support subscription for the container or inherit an existing subscription from a host SUSE Linux Enterprise Server.

I talked about the Base Images and the Language Container Images. For our need to ship the Laravel codebase, we looked at the three SUSE BCIs that support PHP.

The ideal candidate was the SUSE BCI PHP-Apache 8 image. Our Laravel code is actually this year's DevFest Mauritius website. We do not require a database. The conference schedule and speakers details are pulled from a Sessionize.com API and kept as JSON locally. Therefore, a single container to run the PHP code and serve the HTTP content would be fine.

I spoke about the three SUSE BCIs for PHP and possible use cases on different types of PHP scripts or applications we may run.

Okay, it's good that we have a container to run PHP code but it's not great, yet — because it cannot run "our" PHP code. Laravel 10 requires PHP version 8.2 to run whereas the SUSE BCI has PHP version 8.0.30 as latest version.

Most Enterprise Linux distributions support packages for as long as security fixes remain available for the package. That is the case with SLES and PHP 8 here. The latest version of PHP available from the official SLE_BCI repo is PHP version 8.0.30 which will continue to receive security fixes until the end of November this year, then the package will be upgraded to version 8.1.x which will receive security fixes until November 2024.

Then, how can we use the SUSE Linux Enterprise container but with PHP version 8.2?

Comes into the scene, SUSE's own Open Build Service.

I explained how Open Build Service (OBS) allows one to compile software and package the latter for different Linux distributions and different CPU architectures. Then, I mentioned build.opensuse.org where SUSE upstream projects reside. Recently, the Linux Foundation decided to build Kubernetes packages using OBS too. I talked about how openSUSE Leap and SUSE Linux Enterprise share a 1:1 binary compatible codebase.

One could build PHP v8.2.12 packages using build.opensuse.org but... there is actually no need — because v8.2.12 is already built for SLE 15 SP5. 😎 We can simply add the OBS repo to our SLE BCI Apache-PHP container and install the latest version of PHP.

Huh! So, by this time we have a codebase, we have chosen a BCI and we know how to get the latest version of PHP running which is required for our application (i.e the website of DevFest Mauritius 2023). What's next? We need to build a container image that will hold our codebase and be ready for shipping.

So... Let's build it!

Before talking about building containers though, I mentioned that I don't like the idea of simply copying Dockerfiles from the Internet and start using. Writing a Dockerfile is not difficult and a lot of times it requires just a few lines. It also helps us keep things clean and we know what we are doing.

Let's write a Dockerfile then.

During the presentation, I explained what each line does. Especially, why I chained the RUN commands in one line instead of multiple RUN commands. Each RUN command creates an OverlayFS layer and takes up a little more space. In this example, it would have taken an additional 8MB if we had used multiple RUN commands for every CLI command specified.

FROM registry.suse.com/bci/php-apache:8

In the first line, we pull the SUSE BCI PHP-Apache 8 image. Then, we copy our project directory inside the container image at a specific path which we have specified in an Apache configuration. I talked briefly about Apache VirtualHosts.

COPY ./devfest2023 /srv/www/vhosts/devfest2023
COPY ./devfest2023.conf /etc/apache2/vhosts.d/devfest2023.conf

Next, we copy a "repo" configuration file that contains information about the OBS repository.

COPY ./obs_php.repo /etc/zypp/repos.d

The content of the .repo file is available from the PHP package project on build.opensuse.org.

We run the zypper ref command to update the repo database. We update the packages with the --allow-vendor-change option. Without this option, it will not upgrade PHP because the currently installed PHP package by vendor SUSE is the highest version available. By allowing vendor change, the package will be upgraded using newer packages from the OBS repository.

RUN zypper ref; zypper up -y --allow-vendor-change; \
zypper in -y php8-tokenizer php8-iconv php8-intl php8-bcmath \
php8-bz2 php8-ctype php8-gd php8-posix php8-readline

We install a few other PHP libraries that will be required by our Laravel application.

Laravel writes to a log file stored at the storage/laravel.log path. Therefore, ownership of the directory is changed to the user wwwrun which is the user that owns the Apache child processes.

chown -R wwwrun:wwwrun /srv/www/vhosts/devfest2023; \

We enable the mod_rewrite module in Apache because we have a Rewrite Rule in our Apache configuration that forwards all requests to the index.php file.

a2enmod rewrite

Lastly, we make the container reachable on port 80.

EXPOSE 80

Our Dockerfile is ready. We can build the container image.

I explained what each of the options does in the docker build command. After building the image, we can run a container locally to test the application.

docker run —-rm -p 8080:80 devfest:2023

Once again, I explained what each of the option in the above command does.

So, we've built a container image successfully, we've tested our application running inside a container, what do we do next? Deploy to Google Kubernetes Engine (GKE)? Not, yet. We need to push this container image to a registry, from which GKE will be able to pull and deploy.

Hereon, we started talking about the Google Cloud Platform. We needed to enable two services on GCP before we can ship a container and deploy our application. The services are:

• Artifact Registry API
• Kubernetes Engine API

I explained that previously we would use the Container Registry API but that was only limited to Docker container images. The Artifact Registry can hold repos for container images, npm packages, python, etc.

We created a repository in the Artifact Registry, we specified the format as Docker and we selected a region. We discussed about this choice (i.e region) for a while. My usual trick for obtaining the best latency to a "region" is to understand how our submarine fiber cables connect us to the rest of the world. Since, the SAFE/SAT-3/WASC submarine cable connects us to the west side of the European continent, for this example we chose the europe-west1 region, which is in Belgium. Not too far from the landing point in Portugal? 🤔 Anyway, let's continue...

After creating the repository, the GCP console redirects to the repository details page. I encircled the path which we need when pushing the container image to the registry.

Oh... wait. Before pushing our container image to the Google Artifact Registry we need to setup authentication for Docker. Read the instructions here. During the presentation I did not elaborate on the Docker/GCP authentication part as it is purely textbook instruction.

We're almost there. We have built our container, we have set up our repository on Google Cloud, so now let's do the next step.

We tag the local image devfest:2023 (which we built earlier) using the path we saw on the repository page. I explained each item in the command for clarity.

Then, we run:

docker push europe-west1-docker.pkg.dev/devfest2023-403313/mscc/devfest:2023

You can see the progress as each layer is being copied to the registry. When completed, refresh the registry page on the cloud console.

Hereon, we started talking about Kubernetes and its complexity. However, Google (and other cloud providers) offer a Managed Kubernetes Service. Managed meaning — the implementation and related complexities are obsfuscated. Thus, as a developer you should be able to deploy your application in a cluster with minimal effort. That's exactly what Google Kubernetes Engine is about.

You click on the three dots and select "Deploy to GKE".

The first option is to select a container, but here the devfest:2023 container is pre-selected. You can add environment variables which you usually do through the .env file of a Laravel application. Since, we are not using a database or require any other specific info to pass on, we can skip this part.

GKE creates a deployment configuration which defines the state of the cluster. It uses defaults here, e.g the replicas (i.e no. of nodes in the cluster) to 3. All of this information can viewed in the YAML file which is accessible from the page.

The YAML file is read-only at this point. We cannot edit the deployment configuration but we can do so once the cluster is created. Then, we can edit the YAML config to adjust it to our needs or use other "buttons" in the console to scale the cluster up/down, horizontally or vertically.

After the configuration part, the last step is to select whether we want to create a service to expose the cluster. Since, we want our application to be available on the Internet, we expose the cluster on port 80.

After we hit "DEPLOY", GKE starts building the cluster.

For this example, the cluster was ready in less than 5 mins.

Once the cluster is ready, the deployment details page will display information regarding the availability and health of the cluster nodes. At the bottom of the page, the endpoint in the Expose services show the Public IP Address for the deployment. Click on that and you can access your application. In our case, we were able to see the DevFest Mauritius 2023 site hosted on the IP address.

That was my share of contribution to DevFest Mauritius 2023, as speaker this year. I hope everybody who attended the session enjoyed it and learned at least a thing or two. 😊

Yesterday, someone tweeted and complained that he sent two tickets to the certification platform with no response.

Taylor Otwell, the creator of Laravel responded in that conversation thread and confirmed that they are breaking ties with the certification platform.

Taylor's dissatisfaction with the way the certification platform was being managed was very apparent in the tweet that followed.

The certification.laravel.com sub-domain now redirects to the project's homepage while returning an HTTP 302 status code.

$ curl -I https://certification.laravel.com
HTTP/2 302 
date: Mon, 19 Dec 2022 07:38:57 GMT
location: https://laravel.com
cache-control: private, max-age=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0
expires: Thu, 01 Jan 1970 00:00:01 GMT
server: cloudflare
cf-ray: 77be7b4ebb53cb7b-MBA

The HTTP 302 status code indicates that it is a temporary redirection.

FROM composer:latest AS build
WORKDIR /app
COPY . /app
RUN composer install --prefer-dist --no-dev --optimize-autoloader --no-interaction

FROM php:8.2-apache-bullseye AS production

ENV APP_ENV=production
ENV APP_DEBUG=false

RUN docker-php-ext-configure opcache --enable-opcache && \
    docker-php-ext-install pdo pdo_mysql
RUN pecl install redis && docker-php-ext-enable redis

COPY --from=build /app /app
COPY vhost.conf /etc/apache2/sites-available/000-default.conf
COPY .env.prod /app/.env

RUN cd /app && php artisan config:cache && \
    php artisan route:cache && \
    chmod 777 -R /app/storage/ && \
    chown -R www-data:www-data /app/ && \
    a2enmod rewrite

I used the above Dockerfile to build the Laravel container. There are two stages in this build process —

• First, a composer:latest container is used to install the project dependencies.
• Then, a php:8.2-apache-bullseye container is used to run the Laravel application in production.

To be honest, I should have added one more build stage to use NPM to compile the front-end stack... but... well, to better understand the reasons for multi-stage builds, let us look at something simpler.

fn main() {
    println!("Namaste, world! 🙏");
}

The above Rust code does nothing fancy, it just prints "Namaste, world!" with the folded hands emoji, to the terminal. We could pull a Rust container image, e.g rust:1.66.0-alpine3.17 to build and then run the application. It would work, right?

The rust:1.66.0-alpine3.17 container image is 787MB in size. Would you want to deploy a small binary along with a 100 times bigger container to your production environment? Probably, no. That is why we need to build the production container in multiple stages.

FROM rust:1.66.0-alpine3.17 AS build
WORKDIR /app/
COPY . .
RUN cargo build --release

FROM scratch
COPY --from=build /app/target/release/namaste-world /app/namaste-world
CMD ["/app/namaste-world"]

We use rust:1.66.0-alpine3.17 to compile the application and then we copy the binary to another smaller (very small) container, called scratch.

$ docker build . -t namaste-world:latest
[+] Building 0.1s (10/10) FINISHED                                                                                      
 => [internal] load build definition from Dockerfile                                                               0.0s
 => => transferring dockerfile: 74B                                                                                0.0s
 => [internal] load .dockerignore                                                                                  0.0s
 => => transferring context: 2B                                                                                    0.0s
 => [internal] load metadata for docker.io/library/rust:1.66.0-alpine3.17                                          0.0s
 => [internal] load build context                                                                                  0.0s
 => => transferring context: 7.29kB                                                                                0.0s
 => [build 1/4] FROM docker.io/library/rust:1.66.0-alpine3.17                                                      0.0s
 => CACHED [build 2/4] WORKDIR /app/                                                                               0.0s
 => CACHED [build 3/4] COPY . .                                                                                    0.0s
 => CACHED [build 4/4] RUN cargo build --release                                                                   0.0s
 => CACHED [stage-1 1/1] COPY --from=build /app/target/release/namaste-world /app/namaste-world                    0.0s
 => exporting to image                                                                                             0.0s
 => => exporting layers                                                                                            0.0s
 => => writing image sha256:44c98d7123b596ef4b90388ce73ee66391f5f38a04e75440dfb0a4399b436e94                       0.0s
 => => naming to docker.io/library/namaste-world:latest                                                            0.0s

Once the container is built, let's run it.

$ docker run --rm namaste-world
Namaste, world! 🙏

Now, let's have a look at the size of the container images.

$ docker images
REPOSITORY      TAG                 IMAGE ID       CREATED        SIZE
namaste-world   latest              44c98d7123b5   2 hours ago    4.57MB
rust            1.66.0-alpine3.17   87eecbd0d066   38 hours ago   787MB

See, the scratch container image holding the namaste-world binary is below 5MB while the rust:1.66.0-alpine3.17 container image is 787MB. When deploying to production it is best practice to use smaller images for less memory footprint.

Renghen and I talked after I published this post on Twitter & LinkedIn. He shared his views about having a multi-stage build process. It makes more sense if it is part of a pipeline. He does not advise compiling applications using containers. He refers to an example where the compiler requires the GPU and such compilation won't be possible using a container. However, he stated that multi-stage builds makes sense in cases where certain languages have deprecated some features and one might still need those to run an application.

Your application is accessible on the web via routes or call them URIs. They are defined in the routes/web.php file in your Laravel application. The routing feature is provided by a facade.

use Illuminate\Support\Facades\Route;

In its simplest form, a route accepts a URI and a closure (i.e an anonymous function).

Route::get('/greeting', function () {
    return 'Namaste, world';
});

Route::get('/', function () {
    return view('greeting', ['name' => 'Angad']);
});

Route::get('/about', function () {
    return response()->json([
        'name'  => 'Angad',
        'level' => 'Warrior',
    ]);
});

You can return a string, a view or other HTTP responses.

You can register a URI to respond to a specific HTTP verb or respond to multiple HTTP verbs using the match() method.

Route::get($uri, $callback);
Route::post($uri, $callback);
Route::put($uri, $callback);
Route::patch($uri, $callback);
Route::delete($uri, $callback);
Route::options($uri, $callback);

Route::match(['get', 'post'], '/', function () {
    //
});

If a URI should respond to any HTTP verb then you can do so using by using the any() method.

Route::any('/', function () {
    //
});

Route parameters

Route parameters let you capture values from the URL. A parameter is specified by putting string within curly braces {name} in the URL. It can then be accessed by the controller.

Route::get('/blog/{id}', [PostController::class, 'show']);

Then in the specified method in the controller you write the actions that are needed for this value. In the example above, this would be done in the show method of the PostController controller.

public function show($id) {
   // do something with $id
   return $id;
}

This post is a work in progress. I will keep updating it with bits and pieces of useful information regarding Laravel routing for my own reference.

The below commands will generate some files which can be used to edit part of the email content.

php artisan vendor:publish --tag=laravel-notifications
php artisan vendor:publish --tag=laravel-mail

However, the reset of the layout for the emails are found in these two files:

vendor/laravel/framework/src/Illuminate/Auth/Notifications/ResetPassword.php

vendor/laravel/framework/src/Illuminate/Auth/Notifications/VerifyEmail.php

The above files being in the vendor directory are not tracked by git and they will be most likely overwritten when composer updates the packages. However, until I have found a better way to customise these emails, these files are what should be updated.

Then, in the voluminous documentation of Laravel 9, I tried to find how to do it. So far, the best options are:

$url = "https://example.com?key={$value}";

return redirect($link);

Using a named route:

return redirect()->route('route_name',['key'=> $value]);

To install MailHog on openSUSE you need to install Go.

sudo zypper in go

Then, get the Mailhog binary.

go get github.com/mailhog/MailHog

The Mailhog binary will be available in the ~/go/bin directory. You can run it directly from there or add that to your PATH environment.

Once, you've executed the Mailhog binary, the application will be running on port 8025.

ish@coffee-bar:~> ~/go/bin/MailHog
2022/02/27 10:44:03 Using in-memory storage
2022/02/27 10:44:03 [SMTP] Binding to address: 0.0.0.0:1025
[HTTP] Binding to address: 0.0.0.0:8025
2022/02/27 10:44:03 Serving under http://0.0.0.0:8025/

As you can see above, a SMTP service will be available on port 1025. It's part of MailHog and you need to do nothing to configure it.

To check the incoming emails you just have to head to the web application running on port 8025.

To enable your Laravel application to use MailHog, update the .env file with these parameters.

MAIL_MAILER=smtp
MAIL_HOST=0.0.0.0
MAIL_PORT=1025
MAIL_USERNAME=null
MAIL_PASSWORD=null
MAIL_ENCRYPTION=null
MAIL_FROM_ADDRESS=no-reply@example.com
MAIL_FROM_NAME="${APP_NAME}"

All the emails sent using your Laravel app on your local machine will be available to be viewed on the MailHog web application.

I checked the documentation pages about authentication for Laravel Jetstream and Fortify but could not find any mention about changing the redirection path; unless I wasn't looking at the right place.

After some fiddling I understood that the app/Providers/RouteServiceProvider.php file has this const defined as HOME and it holds the path value for redirection after login.

/**
* The path to the "home" route for your application.
*
* This is used by Laravel authentication to redirect users after login.
*
* @var string
*/
public const HOME = '/';

// Define scope within your model
public function scopeThisMonth(Builder $query): Builder
{
    $startDate = Carbon::now()->startOfMonth();
    $endDate = Carbon::now()->endOfMonth();
    return $query->whereBetween('created_at', [$startDate, $endDate]);
}

// Use the scope like below
Product::query()->thisMonth();

Laravel documentation

The whereBetween method verifies that a column's value is between two values.

$users = DB::table('users')
           ->whereBetween('votes', [1, 100])
           ->get();

Read more on this.

For more interesting tips on Laravel you can follow @TheLaravelDev.