Sending Laravel Slack Notifications with a webhook URL

Laravel Notifications support a number of channels, such as email, SMS and Slack. If you follow their documentation for sending Slack notifications you’ll need to setup a bot user with an OAuth token.

If you were creating a new Slack ‘app’ to receive messages this would be the way to go. In my case though I was refactoring some Logging which used the Slack channel with a webhook URL setup. The Slack interface didn’t allow me to setup or find the bot user/OAuth token for an existing App.

In order to use the Notifications class with a webhook I needed to send a simpler message structure than what you see in the docs and use slightly different service configuration.

Slack Service Config

In config/services.php


return [
    'slack' => [
        'webhook_url' => env('LOG_SLACK_WEBHOOK_URL'),

       Use a webhook_url instead of the bot_user_oauth_token structure

        'notifications' => [
             'bot_user_oauth_token' => env('SLACK_BOT_USER_OAUTH_TOKEN'),
             'channel' => env('SLACK_BOT_USER_DEFAULT_CHANNEL'),

Instead of calling the text, headerBlock, contextBlock type methods I just called content()


namespace App\Notifications;

use Illuminate\Notifications\Messages\SlackMessage;
use Illuminate\Notifications\Notification;

class CafeNotification extends Notification
    public function via(object $notifiable): array
        return ['slack'];

    public function toSlack(object $notifiable): SlackMessage
        return (new SlackMessage)

This was enough to get simple notifications going without having to recreate my Slack app in order to setup a bot user and token.

Upgrading to Laravel 11 with Redis and CI

I’m in the process of upgrading my coffee discovery app HadCoffee to Laravel 11. Shift did most of the work, but you always have to tweak a few things.

I found that although my test suite passed locally, the Chipper CI builds were still failing on tests that touched Redis, or cache (which uses Redis in my case).

I needed to update the env variables to connect to Redis. Maybe you do too if you’re on this page 🙂

I’m using the Predis client.


Laravel Model Timestamps without an updated_at

Laravel makes it easy to add created_at and updated_at fields to your models. Just include the ->timestamps() shorthand in the migration, and use public $timestamps = true on the model.

Sometimes though you’ll have high-volume models such as an event log that record immutable things that will never be updated. Storing a redundant updated_at can be a bit wasteful if you’ll never need it, and it tells you nothing new.

It’s easy to customise the behaviour, but perhaps a little hard to discover. I missed it in my searching until Jess Archer told me it was supported.

In the migration

Define your migration like so:

// ...

return new class extends Migration
    public function up(): void
        Schema::create('my_table', function(Blueprint $table) {
            $table->timestamp('created_at', 0)->nullable();
            // define created_at on its own

In the model

By default Laravel will attempt to write to the updated_at column. If you don’t have one it will error.

You can easily disable it like so:


namespace App\Models;

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

class MyModel extends Model
    public $timestamps = true;

    const UPDATED_AT = null;


Done 🙂

Using S3 Lifecycle rules with Spatie Laravel Backups

AWS S3 has a feature called Lifestyle Rules that let you define rules to run a range of transitions on your objects, such as changing their storage class or expiring (deleting) them.

This can be useful to save costs and clean up your object list by removing objects you don’t need to keep forever. You can lean on AWS for the expiry logic without having to program scheduled events to clean up for you.

Lifecyle rules can be targeted to an entire bucket, to objects with a path prefix, or to objects with a particular Tags.

Spatie Laravel Backup is a popular Laravel package for taking site/database backups.

It can be configured to write to various ‘disks’. If you’re using the S3 disk it is possible to Tag those backups for targeting by the Lifecycle rule.

Creating the rules in S3 and targeting a tag

S3 Console screenshot showing Management lifecycle rules

In my case I will be targeting a tag called fadeout with a value of true.

This rule will transition objects to the Standard Infrequent Access storage class after 30 days, and then delete them after 60 days. It also only applies to objects over 150kB.

Tagging backups that Laravel Backup uploads

To have your backup objects tagged in order for the lifecycle rule to take effect you’ll need to an an option to your Laravel fileysystems.php config file.

Assuming you are using the s3 disk, you’ll need to add a backup_options value to your S3 config array like so:

's3' => [
  'driver' => 's3',
  'key' => env('AWS_ACCESS_KEY_ID'),
  'secret' => env('AWS_SECRET_ACCESS_KEY'),
  'region' => env('AWS_DEFAULT_REGION'),
  'bucket' => env('AWS_BUCKET'),
  'url' => env('AWS_URL'),
  'backup_options' =>
     ['Tagging' => 'fadeout=true', 'visibility'=>'private'],

Backups are private by default, but because we’re overriding the options array we need to specify it again.
The format of the Tagging key is url encoded as shown.
The Tagging and visibility keys are case sensitive as shown.

With that in place you can keep your recent backups without cluttering your bucket 🙂

Check Australian Business Number (ABN) in PHP and Laravel

Note: Newer versions of Laravel now have a different interface for creating custom validation rules. See the ValidationRule class. This post hasn’t been updated yet. (2024).

ABNs use a checksum, so their basic format can be validated. There is also an API to check that the ABN also corresponds to a real business, but as a preliminary check this function will tell you that the format is correct.

See the rules behind the check here.


// Remove spaces from an ABN string before passing to function.

function validAbnFormat(int $abn): bool
  if (strlen($abn) !== 11) {
    return false;

  $nums = array_map('intval', str_split($abn, 1));
  $nums[0] -= 1;

  $weights = [10, 1, 3, 5, 7, 9, 11, 13, 15, 17, 19];

  foreach($nums as $pos => $num) {
    $weight = $weights[$pos];
    $nums[$pos] = $num * $weight;

  $sum = array_sum($nums);
  return $sum % 89 === 0;

Creating a Laravel Validation Rule

If you would like to validate ABNs in a Laravel application you can register a custom validation rule that you can use in Form Requests or Validators.

Create the new rule class using artisan

php artisan make:rule Abn

Then use a variation of the function above to validate the ABN. The Abn class should look like this:


namespace App\Rules;

use Illuminate\Contracts\Validation\Rule;

class Abn implements Rule
    public function __construct() {}

     * Determine if the validation rule passes.
     * @param  string  $attribute
     * @param  mixed  $value
     * @return bool
    public function passes($attribute, $abn)
        $abn = str_replace(' ', '', $abn);

        if (strlen($abn) !== 11) {
            return false;
        $nums = array_map('intval', str_split($abn, 1));
        $nums[0] -= 1;
        $weights = [10, 1, 3, 5, 7, 9, 11, 13, 15, 17, 19];
        foreach($nums as $pos => $num) {
            $weight = $weights[$pos];
            $nums[$pos] = $num * $weight;
        return array_sum($nums) % 89 === 0;

     * Get the validation error message.
    public function message(): string
        return 'Invalid ABN';

You can then use this validation rule by importing the class and adding it to your set of rules for an input.


use App\Rules\Abn;

// ...

$validator = Validator::make(
   ['abn' => ['required', new Abn]]

Testing Form Request Validation in Laravel

I recently got stuck writing a test for a Controller which uses a custom form request for validation and authorization. Though the form request worked correctly for real requests in the browser, it was being ignored from the Feature test. In other words the Controller action would run even with invalid test input and even when the form request was hard-coded to specifically block authorization.

Incorrect Approach

I had been creating the form request, instantiating the Controller I wanted to test and sending the request. This bypassed the checks, presumably because the middleware that triggers validation isn’t run in this context.

function test_invalid_request()
  $request = CafeStoreRequest::create('cafe', 'POST', ['cafe_name' => '']); //should fail
  $controller = new App\Http\Controllers\CafeController();
  $response = $controller->store($request);


What Worked

Instead of manually creating a controller, I needed to route the request through the HTTP layer so that the middleware would do its thing and trigger the appropriate error.

function test_invalid_input()
  $response = $this->post(route('', ['cafe_name' => '']));

Create a Light & Dark Mode Control with Tailwind & Alpine

Some users prefer darker colour themes to prevent eyestrain, while others like having the choice depending on their lighting conditions. Tailwind makes it easy to specify different colours to use depending on which mode is active.

By default Tailwind responds to the prefers-color-scheme media query, which passes through the users’ operating system preference. You can also configure it to alter the colours by inheriting a ‘dark’ CSS class name from a parent element. This lets you to build your own UI control to switch modes, so that users can have a different preference for your site than their OS.

To do this, change the darkMode property in your tailwind.config.js file

// tailwind.config.js

module.exports = {
  darkMode: 'class',

Controlling The Active Mode

Now that Tailwind is configured to compile dark mode colours based on the .dark class name, we need a way to toggle that class name. We also need to persist the selection between sessions and page loads.

I’ll be using localStorage to store the user’s preference and AlpineJS to handle the toggling action. Alpine is a lightweight JS framework that works with your markup and doesn’t require a build step.

As well as storing the user’s preference we’ll need to apply it as early as possible during page rendering to activate their desired mode.

How it Works

  • Tailwind generates classes that are applied when dark mode is activated
  • When our page loads we see if the user has set an explicit choice of mode for our site (using the UI control we provide)
  • If they’ve asked for dark mode we apply the CSS class
  • If they have not set a preference, but their implicit preference via their OS is for dark mode we apply the CSS class
  • Otherwise we’ll fall back to the default light mode

When our user makes a specific choice using the on-page UI we’ll update the document class and also save their preference in localStorage for subsequent page loads.

UI Control

Here’s the code to provide light & dark mode buttons. Alpine uses the x-data property to store the state for our component. x-init runs on setup and syncs our local state with what was previously stored in localStorage.

      mode: '',
      setColorMode: m => {
          if (m === 'dark') {
              localStorage.setItem('colorMode', 'dark')
          } else {
              localStorage.setItem('colorMode', 'light')

  x-init="() => {
      const m = localStorage.getItem('colorMode');
      if (m !== 'dark' && m !== 'light') return;
      mode = m;
    @click="mode='light'; setColorMode('light');"
    :class="{'font-bold': mode === 'light', 'font-thin': mode !== 'light' }"
    class="underline px-2 py-1 rounded-md border-white hover:bg-gray-100 dark:hover:bg-gray-800"
    @click="mode = 'dark'; setColorMode('dark');"
    :class="{'bg-gray-700 text-gray-200 border border-solid border-gray-600 font-bold': mode === 'dark', 'font-thin': mode !== 'dark' }"
    class="underline px-2 py-1 rounded-md hover:bg-white dark:hover:bg-gray-800"

Persisting The Selection

Of course as users browse around your site you don’t want them to have to re-apply their choice of colour mode every time they visit a new page. We’ll use a bit of JS near the top of our document to reapply their preference as early in the render as possible.

  <!-- other bits -->
  <link rel="stylesheet" href="css/style.css" type="text/css">
  <script src="detect-mode.js"></script>
// detect-mode.js
// set initial color scheme

let explicitelyPreferScheme = false
if (window.localStorage) {
    if (localStorage.getItem('colorMode') === 'dark') {
        explicitelyPreferScheme = 'dark'
    } else if (localStorage.getItem('colorMode') === 'light') {
        explicitelyPreferScheme = 'light'

if (explicitelyPreferScheme !== 'light' && window.matchMedia('(prefers-color-scheme:dark)').matches) {

This will apply dark mode if our visitor has selected it from the UI control above; or if they have not set any preference but their OS is set to use dark mode.

Live Demo

You can change your preference and reload this page to see it persist.

Enjoy the darkness!

Fixing Curl Error 35 with WordPress API calls

I recently had an issue where a WordPress website I was building could not connect to itself for wp-cron or background tasks.

This was the error:

curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number

It turns out I had a faulty nginx configuation, and the server block was missing the ssl directive. The certificates worked in both Chrome and Firefox without warnings, but they weren’t doing what the needed to for curl to work.

server {
	listen 443 ssl;
	root /var/www/example/;

Adding ssl to the listen line fixed the cURL error and wp-cron

Confirm Before Deleting WordPress Trash

I recently watched someone who using their phone and tablet for everything manage posts on their WordPress blog. One they intended to keep ended up in the Trash by mistake. Restoring it is easy enough, but the ‘Restore’ and ‘Delete Permanently’ links are very close to each other on a mobile screen and I got a little nervous seeing them tap restore 30px away from the kill button.

I’ve created a simple WordPress plugin that adds a confirmation step in the admin area before deleting or emptying the Trash.

It’s a pretty simple thing, just a little JavaScript to make sure the click was deliberate. Give it a go if you’d rather have an extra click than possibly try and recover a post from a site backup.

Download the Plugin

Trash Fail Safe for WordPress.