stefanzweifel.dev

Show Remaining Characters in a Filament Text Input

2026-04-04T21:00:00Z

At work I’ve recently brought up the idea of showing a “remaining characters indicator” to our Filament form components. A small circle that appears when you soon reach the maximum character limit and that turns red once you’re over that limit.

Here is a quick video on how this feature would look like:

After internal discussions, we’ve decided to scrap the idea again, but I thought why not share my hacky solution with the rest of the world?

Adding the Indicator #

I’m in a Laravel 12 and Filament 5 project here and abused the suffix and extraAttributes methods on a TextInput-component to make this work.

This is how my form field declaration looks like.

TextInput::make('name')
    ->label('Name')
    ->required()
    ->maxLength(50)
    ->suffix(new HtmlString(Blade::render('<x-remaining-characters />')))
    ->extraAttributes([
        'class' => 'relative',
        'x-data' => "{
            maxChars: 50,
            get charCount() { return \$state ? \$state.length : 0 },
            get remaining() { return this.maxChars - this.charCount },
            get percentage() { return (this.charCount / this.maxChars) * 100 },
            get isOverLimit() { return this.charCount > this.maxChars },
            get showCount() { return this.remaining <= 40 || this.isOverLimit },
            get strokeColor() {
                if (this.charCount === 0) return '#e5e7eb';
                if (this.isOverLimit) return '#ef4444';
                if (this.remaining <= 40) return '#f59e0b';
                return '#3b82f6';
                },
                get circumference() { return 2 * Math.PI * 10 },
                get strokeDashoffset() {
                    const progress = Math.min(this.percentage, 100);
                    return this.circumference - (progress / 100) * this.circumference;
                }
            }",
        ]),

The important pieces here are the values passed to maxLength and maxChars which dictate the maximum allowed length of the input. Then there is a condition to check, if the user is near the maximum length (this.remaining <= 40).

The rest of the Alpine.js code is there to calculate the right text color and stroke offset of the little circle we display in our Blade component.

And the code below is the content of the <x-remaining-characters /> Blade component located in resources/components/remaining-characters.blade.php.

<div data-class="absolute bottom-1 right-1 select-none">
    <div class="relative w-6 h-6 flex items-center justify-center">
        <!-- Character count in center -->
        <span
            x-show="showCount"
            x-cloak
            class="text-[10px] font-bold absolute z-10 leading-none"
            :class="{
                'text-red-600': isOverLimit,
                'text-amber-600': !isOverLimit && remaining <= 40,
                'text-blue-600': !isOverLimit && remaining > 40
            }"
            x-text="remaining"
        ></span>

        <!-- SVG Circle (24px) -->
        <svg
            class="transform -rotate-90 absolute"
            width="24"
            height="24"
            viewBox="0 0 24 24"
        >
            <circle
                cx="12"
                cy="12"
                r="10"
                fill="none"
                stroke="#e5e7eb"
                stroke-width="2"
            />
            <circle
                x-show="charCount > 0"
                cx="12"
                cy="12"
                r="10"
                fill="none"
                :stroke="strokeColor"
                stroke-width="2"
                :stroke-dasharray="circumference"
                :stroke-dashoffset="strokeDashoffset"
                class="transition-all duration-200 ease-out"
                stroke-linecap="round"
            />
        </svg>
    </div>
</div>

As you can see, we use the values from our Alpine.js component here to change the text color, to show the remaining allowed characters as well as the offset of a SVG circle.

This approach worked well for a proof of concept. As mentioned, we’ve collectively decided that we don’t even want to have such indicators in our app, so we scrapped the idea again.

If this would have landed in production, I definitely would have turned the code into a more reusable system, by either creating a macro or creating a dedicated TextInputWithRemainingCharacterCount-component for this.

Reply to Stefan

Laracon EU 2026 Recap

2026-03-12T21:00:00Z

It has already been a week since Laracon EU 2026 ended. I attended with the whole Trenda-team, and we remained in Amsterdam for the rest of the week to work on some projects there.

Laracon is always a great event. I saw many familiar faces from previous installments, internet friends who live far away. And this time I tried to make an effort and talk to more people than usual. (Still forgot to take any selfies.)

The talks this year were great. There were only 1 or 2 which I think weren’t a hit.

The following talks were especially great, and I will have to watch the VOD (Day 1, Day 2) again and take notes:

Dan Harrin: “Write better abstractions: lessons from an import system” #

Dan basically presented how they decide how to abstract functionality in Filament PHP. Their approach of Description over Instructions was brilliantly explained in his talk.

Definitely something I would like to adopt in my own packages as well as in work projects, where we build reusable components.

Ryan Chandler: “Handling the unhappy path” #

Ryan talked about some not-well-known features and functions of the Laravel framework.

One thing that stuck out was the… report() and response()-function on custom exceptions. I know and used these functions in projects before, but it was great seeing more people exposed to these features and a reminder that they exist.

Shortly after, Ryan launched lesserknownlaravel.com.

Tobias Petry: “One billion rows with Laravel“ #

As always, Tobias shined with great visual slides that complemented his talk perfectly.

He talked about TimescaleDB in PostgreSQL and how you can use aggregates to precompute large chunks of timeseries events.

Great talk and a good reminder to explore PostgreSQL more and maybe start migrating my MySQL databases.

Peter Suhm: “Unblocking your users with AI“ #

Peter shared some great practical tips on how to help your users get activated in your app.

He mentions the Three Points of Paralysis that users might feel:

The Blank State: “I don’t know where to start.”
The T-Junction: “I don’t know which one.”
The Maze: “I don’t know how to find it.”

Instead of showing users a cluttered UI, we might show them a prompt that helps them overcome the Blank State. He explained this with form builders. Instead of manually clicking things together, let the user describe the outcome they want and let the LLM generate a JSON structure for a form.

This shouldn’t replace the UI form builder, but give users a good starting point.

For the T-Junction, he used the same example with form builders. Maybe users don’t know if they have to select a radio or checkbox list for a field. If possible, let the app help your users and provide a good first guess. For the Maze, he built basically a little search agent that uses vector embeddings of form answers to answer questions like “Did visitors like the conference?”.

Simon Hamp & Shane Rosenthal: “NativePHP” #

I’ve bundled Simon and Shane here, as they both work on NativePHP and both gave talks about NativePHP.

What they accomplished in the last few months is amazing. They pushed through the negativity they received on Reddit and other social media sites and improved NativePHP more and more. Bundlesize and Android support got better.

And the advancements Shane showed in this talk – that they now create real-native C code and render real native iOS or Android elements was mind-blowing.

Simon dropped the phrase “Just give it 5 minutes” and it really stuck with me. I have an idea for a mobile companion app for a side project of mine and will definitely give NativePHP a shot.

Luke Kuzmish: “Effective Code Reviews: What NOT to Do“ #

Luke did a great talk reminding us all to take out the ego of code reviews. He mentioned:

Standardize the review process.
Automate as much as possible through code (linting, formatting, etc.).
Read your own pull request on your own and make sure the CI pipeline is green.
Use Conventional Comments as a guiding framework when leaving notes.

Was a good reminder to use Conventional Comments categorizes more in my code reviews again.

Joe Tannenbaum: “State of the Frontend” #

Joe gave us an update on the frontend tooling Laravel provides. He showcased some new Inertia features that are coming in the next major version.

I personally haven’t used Inertia yet. With my limited time, I get more done using Livewire and Filament. … but I really want to build at least one little project using Inertia. Maybe I will rewrite my little “read-it-later” app using Inertia one day, as that project already relies on being run in Livewire SPA mode.

John Drexler: “Ship to Production on DAY 1” #

John talks about how to tackle big projects by solving the hardest problems first and then shipping the changes to production fast – maybe behind a feature flag to make sure not all users see the changes yet.

The example he brought up is adding support for organizations in the Laravel Forge codebase. Adding this had major consequences to the database and required adding new columns to many tables. This is a hard problem that has to be tackled anyway. By solving it first, you already pushed a big rock out of the way of your project.

He also brings up the concept of a Mind Palace where you can discuss ideas and solutions, but reminds us to test these hypotheses by shipping to production early on. An assumption made 3 months ago might not hold up today.

The Strangler Pattern was also mentioned in which break your project down into vertical slides, small PRs that you can easily ship into production.

In general, a very good talk I have to revisit and take more notes on.

As you can see, it’s quite a list. I will have some note taking to do in the next few days.

Reply to Stefan

Podcasts 2026

2026-03-05T21:00:00Z

It has been a while since I’ve written about the podcasts I listen to. I had a little series going in 2020, 2019 and 2018, but didn’t update you in – checks notes – the last half decade.

The trend that picked up in 2019 and 2020 continued over the last few years: My overall podcast listening time continued to drop.

I previously used to listen to most episodes while working out at the gym, but I’ve basically stopped doing this as I got distracted way to much and didn’t focus on the workout.(I now just listen to various techno playlists during those valuable workout hours)

The current podcast subscription list goes like this:

Cortex: Previously a podcast where Myke Hurley and CGP Grey talked about their productivity setups and general life stuff. CGP Grey left/is on hiatus and the podcast is now a monthly interview with another internet personality about their productivity setup.
The Climate Denier’s Playbook: Two comedians with master's degrees in Climate Science & Policy and Urban Planning, who use that combination to debunk climate misinformation. Each season-based episode picks apart a specific denial argument — things like EVs being worse than trucks, or geoengineering as a substitute for emissions cuts — and tears it apart with research and jokes. A natural companion to the Climate Town YouTube channel if you're already watching that.
Mostly Technical: Podcast by Aaron Francis and Ian Landsman were they mostly talk about technical stuff. In the past few months they talk more about AI and how recent developments in this space changed their daily work.
99% Invisible: Stories about design and architecure. Last time I wrote that I didn’t like their trajection their on. I still have them in my feed so they are doing a good job again.
Articles of Interest: Started as a mini-series within 99% Invisible — so a natural fit alongside it. Hosted by Avery Trufelman, it covers topics like the rise of casual wear, the environmental impact of the textile industry, and why womenswear doesn't have pockets. Each season takes a thematic approach, which makes it feel more like an audio documentary series than a regular podcast.
BBC: Just a Minute: A BBC Radio 4 comedy panel game running since 1967, where the goal is to talk for sixty seconds on a given subject without hesitation, repetition or deviation. The comedy comes from contestants trying to bend those rules while catching each other out. Good background listening and a nice palate cleanser between heavier shows.
No Such Thing as a Fish: A weekly podcast by the researchers behind the BBC panel show QI, where each of them shares their favourite fact they've come across that week. The facts are genuinely surprising and the hosts have good chemistry. Very easy listening.
Notes on Work: Brief thoughts and insights from Caleb Porzio. Caleb is the creator of Livewire and Alpine.js, so if you're in that corner of the web dev world it's a nice window into how an indie open source developer thinks. Episodes are short and come out frequently — easy to keep up with.

Swiss Specific Podcasts #

These podcasts are either very related to Swiss news or politics or are spoken in Swiss German.

SRF: Echo der Zeit: My daily ~30 minutes news update on what’s happening in the world.
SRF: News Plus Hintergründe: Was previously called Hotspot. They release a series of podcasts about a certain topic every month or two. Well researched and worth a listen.
Republik: Dritte Gewalt: A long-running podcast with two journalists about legal cases in Switzerland. Great crew and episodes.
Republik: Gute Frage: A newer podcast in the Republik Podcast universe where the three hosts discuss a “Gesellschafts” question.

I’m sure I forgot to add some podcasts I briefly listened for a while or where I just enjoyed a handful of episodes of them.

Also made myself a note to share my podcasts lists next year again.

Reply to Stefan

Recap 2025

2025-12-31T17:00:00Z

As has become tradition in my developer bubble, a recap on my 2025.

Work #

I start with the work section, as there was a huge change this year: I left 2media/CLARK after 12 years (!) of working there.

A lot happened at this company in the past 16 months that are worthy of a book, but in short: I couldn’t take management seriously anymore and I got bored. I felt like trapped in a cage. Or like rare Pokémon-card you keep wrapped in plastic in your drawer.

Every single feature or code change was discussed to death. Meetings to prepare other meetings. I lost all interest and the momentum faded.

On the day the “You have to leave” thought was locked in, a new job opening was announced for Laravel Forge. I thought “this is your chance” and put everything down, wrote my application and publicly shared that I applied.
Unfortunately I never heard anything back besides the “we received your application email”.

Sandro from Trenda saw my social media comment and reached out and mentioned, that they are looking for an additional developer to join the team and if I would be interested to rejoin the team.

After a quick meeting, I’ve signed the contract and handed in my resignation at CLARK and since October 1st I’m back at Trenda.

I’m grateful, that Sascha and Sandro took me back. The current economic situation is tough for many and there are layoffs happening everywhere. Grateful that this transition was short and that I’m back at Trenda.

The first three months are now over and I can sincerely say this was one of the best decision I’ve made in 2025. We as a team work well together and I was able to ship great new features to the platform already.
Something I dearly missed from the last few years at the previous company.

Personal #

The changes in the work life bleeds in my personal life. Only now I’ve noticed, that I was severely stressed out for many months. Being the sole developer and sole technical person for an entire business unit isn’t great.

The change of employer and being in a relationship did wonders. I have a positive outlook for my life again, am in a good mood way more and sleep much better.

I would also say I’m more fit. Not necessarily on a cardio-fitness level (46 VO2 max) or on a strength level (I lift the same weights as a year before), but in an overall way.
I gained 10 kg of mass over the course of the last 12 months and I feel and look much better now.

Having a partner now to – whom I can talk about anything and everything – helped my mental health a lot. His smile always calms me down and let’s me forget the stress of the current day.

Speaking of mental health; my addiction to social media still plagues me. I check the networks way too much without any benefit.

In the middle of the year I’ve started blocking the most time consuming networks through Little Snitch. Now anytime I visit the webpages in my browser, I get a blank page.

I think I just miss old Twitter and the whole vibe that came with it. Or I’m still disappointed how Twitter turned out to be after the owner change.

2026 is the year where I would like to be “less online”. I think do less will become my general theme for 2026.
Do less doom scrolling. Do less scattered work. Spend more quality time with friends and family and do more things that bring joy.

Open Source #

Speaking of doing less: Open Source work. My contribution to my own open source projects stagnated this year.

After 2 years, I released a new major version of git-auto-commit this summer. I needed the time to get the courage to release the changes. I always had the thought in my head, that I need more time to think about it. Test the change. Make sure nothing breaks. But still, I broke workflows of others and that wasn’t a great feeling.

My PHP packages didn’t get as much love either. There are many open issues that nag at me.
Over the holiday break I worked on laravel-backup-restore, but that was not enough. I will soon go through all those projects and decide, which project I’m going to put my focus on the next year and which will be put on the backburner or be archived.

I still love working on these projects, but I need to find a good workflow for myself to give me dedicated time to work on them. Like “every second Tuesday evening you work 2 hours on this repository”.

Swiss Laravel Association #

Another big thing in my life right now is the Swiss Laravel Association and the Laravel Switzerland meetups.
This was the first year where we took over from Ruslan and organised 12 meetups (with 2 speakers each) and 1 PHPverse watch party.

The first few months were rough, until we figured out a good workflow how we should organise us. Like who should look for locations, who should look for speakers.
Now after a year, I think we have found an okay workflow, that keeps the show running.

I’m especially proud that many new faces showed up to the meetups. This shows us, that there are lot of Laravel devs out there in Switzerland that are looking for a community.
Lots to come in 2026. New locations. A redesigned website. More collaboration with other international meetups.

Epilogue #

As I wrote last year, I have a good outlook on my life. My partner and I celebrated our first anniversary this year and plan to move into a new apartment together next year. Fingers-cross that we find something affordable in the greater Zürich area.

Work fulfills me again and I see much potential in my work at Trenda.

In 2026 I would like to read, write and publish more. Scrolling through my RSS reader and reading blog posts from other developers or creatives brings me a lot of joy.
I would like to contribute my part here and share more of my thoughts on work or on life.

Health wise I wish that the tremblings settle in my family. In addition to the health scare of 2023, we battled with a cancer diagnosis this year. Thankfully, the person went to an early screening and the tumor was discovered early on. Removal and treatment went swiftly and there’s nothing left in the body.

But man. This diagnosis was devastating when I heard about it. Many evenings I was curled up in bed thoughts racing about potentially losing this person or that they had to suffer for a long time.

So please, tell your loved ones to go do a mammography screening or prostate exam or a general check up, even if it’s not the most comfortable procedure. It can save lives.

Let me bring this back to a positive note. 2025 was a great year for me. I love life and have a great positive outlook for the years to come. See you all again in 2026.

If you like these recap-posts, you can find others from Duncan, Dennis, Paweł, Will, Rathes or Justin.

Reply to Stefan

Introducing laravel-tfa-confirmation

2025-02-02T12:00:00Z

Earlier today I tagged v1 of a new Laravel package. laravel-tfa-confirmation – as the name might suggest – the package has to do with two-factor-authentication.

Let me explain what the package does and how it could be beneficial for your project.

What problem does the package solve? #

The package was born from my work a Trenda in 2024.
In the app, users can enable 2FA for their account and we wanted to force users to enter their 2FA code if they visited certain sections of the app (eg. the team settings page).

However, they shouldn't have to enter their 2FA code everytime they visited the page. Only in a given time period.

This is basically the same behaviour as the "Password Confirmation" feature in Laravel, but for 2FA codes. It's also similar to GitHub's sudo mode feature.

How does it work? #

After installing the package through composer, you get a new RequireTwoFactorAuthenticationConfirmation-middleware, which you can apply to a single route or an entire route group.

Based on a configurable timeout, your users is either forced to enter their 2FA code or is being redirected to the intended route. (Probably important to note, that the package depends on laravel/fortify and that you have to use Laravel Fortify as your 2FA "provider".)

The package provides the routes and controllers to ask for a 2FA code and to verify that the entered 2FA code is valid. The "validation" is then stored in the session for a configured time; thus preventing the user from being asked a 2FA code again.

The package actually listens to the Laravel\Fortify\Events\ValidTwoFactorAuthenticationCodeProvided -event fired by Fortify. This has the added benefit, that users don't have to enter their 2FA code again, if they just have logged in and confirmed their 2FA code. This streamlines the user experience, if for example you apply the middleware to your admin-panel. Users then don't have to enter a 2FA code twice, if they just logged in.

What the package doesn't provide #

The default challenge view presented to users to confirm their 2FA code is not styled at all.

The default challenge view shipped with the package is not styled at all. You as a developer have to apply the styles on your own.

I've thought as the the design of each app differs anyway and there is no default-style for Laravel apps, it does not make sense to ship styled HTML. ^[1]

If you use this package, you have to publish the view and update the template accordingly.

Outlook #

I'm using v1 of the package already in my side projects to protect my Filament admin panels with a 2FA code.

In my biased view, I think v1 of the package works great and I encourage you – dear reader – to give it a try in your project.

Nevertheless, I have ideas for future improvements to the package, but I just haven't nailed the API yet:

Custom session lengths for certain actions #

Right now the package has 1 timeout configuration. If, for example, you want that users have to enter a 2FA code every 24 hours to access an admin panel, but every 10 minutes if they access their billing settings, this doesn't work yet.

There is just one challenge-view and the "challenge confirmation" is stored in the session through a detached event listener. The code in the event listener currently doesn't know, for which challenge a confirmation should be stored.

I think I would have to add some sort of hidden "name"-field or "name"-session value to make this all work.

`ConfirmsTwoFactor` Contract #

Already in the code base, but not used yet is a ConfirmsTwoFactor contract. My idea is to add this to a model like User or Team.

In userland, developers could then write code to determine if a challenge should be shown and or how long the confirmations lasts. For example, a team could enable a setting that forces users to confirm a code every 15 minutes for all their users; even when the default value would be every 24 hours.

As you can see, I've got some ideas for this package. For now, I'm happy with v1 and will tinker with a neat API for the other features.
If you have any feedback, please reach out!

If you think this is a bad idea or have a great idea for a default design, feel free to send in a pull request ↩︎

Reply to Stefan

Recap 2024

2024-12-31T12:00:00Z

Another eventful year comes to an end. As it has become tradition, here's my recap of 2024.

Personal #

I deviate from my previous recaps and want to share some personal thoughts.

2024 was a whirlwind of a year.

It started with an amazing two-week vacation with my gym buddies on a remote island and a trip to Amsterdam for my first-ever conference, which was Laracon EU.
I met so many internet friends there and had a blast. Can't wait until next February to see many friends again. (If you see me at Laracon, please come by and say "Hi!".)

In March, I also started working for Trenda. Thanks to attending the Laravel Switzerland meetups, I met Sascha – one of the founders – and got this amazing opportunity to work for them. It was only for one day a week, but it was a breath of fresh air to work in a small team again. Not many meetings. Shipping features and improvements fast to customers.
However, I handed in my resignation and ended the work relationship by the end of this December – for now. Working for two companies got the better of me. As Sascha and Sandro regularly go to the Laravel Switzerland meetups (more on this later), I will stay in contact with them.

Sports-wise, I've fallen a bit into a slump. I'm still going to my local gym seven days a week, but didn't make much progress this year. I had to pause training due to injuries or sickness a couple of times this year.
Next year I'm going to change this. Over this holiday break, I want to change my fitness routine and create a better training plan. I also would like to incorporate cardio more into my training. My goal is to run a local race in December 2025.

Summer and autumn were great, though. I met friends and family for hikes, bike rides, dinners, or evenings at the cinema. In general, I was way more open and adventurous this year. I said Yes! to more things and didn't regret it a bit.

I've always been quite introverted, and making new friendships or connections was brutally hard all my life. But since I turned 30, started taking the gym routine more seriously, and attending those Laravel meetups in Switzerland, I've changed. Talking to strangers got easier. I enjoy most of the conversations I have and almost always learn something new or get a fresh perspective on things.

Speaking of meetups, Ruslan reached out to me and some other regulars to ask if we could help take over the meetup from him, as he is traveling the world by the end of the year.
So together with Jan, Philipp, Sandro, and Sascha, I've founded the Swiss Laravel Association. Together we will organize the Laravel meetups going forward. (The next one on January 30th will be awesome.)

Rambling on here, my social media usage declined further this year. Removing all social media apps from my phone and blocking the URLs in my local network using my Pi-Hole and Little Snitch brought some much-needed calmness to my life.

I still miss the olden days of Twitter. Discovering new programming projects or fun developers and like-minded people gave me a lot of joy. I felt less alone in this world.

Mastodon and now Bluesky filled this void a bit, but the fragmentation and general vibe online make me believe that the era of social media is now truly over.

I now fill my free time by reading or listening to books or catching up in my RSS reader.

Work #

Work was a whirlwind as well. As mentioned, I worked for Trenda a bit, which was really, really great. It gave me a glimpse into another company and development culture.

At 2media/CLARK, I was involved in many projects, most of them hidden behind the veil of "internal access only." My role at this company has also morphed over the last few years from "developer" to "general problem solver." I like solving problems – big and small – but I don't necessarily enjoy creating business reports for managers who constantly change the requirements.

Losing my developer colleague of 12 years from the team by the end of this year was also quite the blow. The next few weeks and months will be challenging, but I'm sure I can find a good solution with my managers/team leader.

And if not, I'm sure I will find a great team I could join that values my abilities and experience.

Open Source #

On the open-source side of my work, I mostly did the regular maintenance work: adding support for new Laravel, PHP, and Node versions and the odd new feature release.

I wish I would have more energy to work on open-source projects again. My todo list and Obsidian vault are filled with project ideas I would like to explore. Most of them don't necessarily have to turn into open-source projects but are still problems I would like to find solutions for.

Next year, I want to carve out at least one evening per week dedicated to personal coding. Be it working on specific open-source projects or just tinkering with new technology or a new tool. (Watching Ryan's Rust For PHP course is very high on my to-do list, for example.)

Epilogue #

2025 looks bright. I think I never had such a positive outlook in my life. At the beginning of the year, I struggled with burnout and depression. I felt alone, unsure what my purpose in life should be.

These thoughts are all gone now. Starting my first romantic relationship later this year was probably the biggest force that pushed these thoughts away.
My calendar is already sprinkled with lots of events with friends and family or dedicated alone time for concerts or hikes.

I can't wait to see what 2025 will bring to me.

Special thanks to Lu and Ivan for spending time with me this year. Your presence made an enormous impact on my life.

If you enjoy reading these recap posts, here are a few from my internet friends you might enjoy as well:

Reply to Stefan

On Founding the Swiss Laravel Association

2024-11-15T12:00:00Z

A few weeks ago we signed the founding documents of the Swiss Laravel Association.

While Ruslan goes on an adventure around the world, we want to keep the momentum going and keep organising the monthly meetups happening throughout Switzerland.

The association currently only consists of 5 members and we're currently still figuring out how membership and sponsoring should actually work.

Right now we're focused on organsing the next events in January and February 2025.

It's all quite exciting. Eventhough Switzerland has a strong association-culture with sport clubs everywhere, I was never part of one; and especially not part of the executive committee steering the whole thing.

We've shared more about the future at the last meetup. You can find the recording of the talk on YouTube.

Reply to Stefan

Deployer: Build and Cache Frontend Assets once using GitHub Actions

2024-08-03T12:00:00Z

When I joined Trenda earlier this year, one of the first tasks given to me was adding support for zero downtime deployments.

I've written before how I use Deployer and how I trigger deployments using GitHub Actions.

In contrast to other projects, at Trenda, we don't commit the compiled CSS and JavaScript files to the repository. The files need to be compiled on each developers machine and during deployment.

Originally we ran npm ci; npm run build; on each deployment on each server. This works, but it makes for slow deployments.

One thing we noticed is that the compiled assets don't need to change on each deployment. Not every release changes the design of the app or adds new JavaScript functionality.

Sandro suggested that we somehow could use the "actions/cache"-Action here.

At the same time we were discussing the way forward, the Flare team shared "Rethinking deploys at Flare", in which they mention that they use a package called Airdrop to cache build assets.

A quick test showed that this would work for us as well, but Sandro's approach with using actions/cache would not require another composer dependency, and we would remain in "GitHub Actions land".

GitHub Actions Workflow for Deployer #

We took the workflow I've shared in 2021 to trigger deploys manually and added steps to build and cache the frontend assets. The steps look like this:

# Workflow triggers and more

- name: Install and cache composer dependencies
  uses: ramsey/composer-install@v3

- name: Frontend Assets Cache
  uses: actions/cache@v4
  id: frontend-assets-cache
  with:
    key: frontend-assets-${{ hashFiles('**/vite.config.js', '**/package-lock.json', '**/tailwind.config.js', '**/resources/**', '**/vendor/filament/**/*.blade.php') }}
    path: public/build/*

- uses: actions/setup-node@v4
  if: steps.frontend-assets-cache.outputs.cache-hit != 'true'
  with:
    node-version: 22
    cache: 'npm'

- name: Install Dependencies
  if: steps.frontend-assets-cache.outputs.cache-hit != 'true'
  run: npm ci

- name: Production Assets Build
  if: steps.frontend-assets-cache.outputs.cache-hit != 'true'
  run: npm run build

# More steps to deploy the app

The important part here is the key we generate in the "Frontend Assets Cache" step. The hashFiles-function generates a unique hash based on the files that match the patterns passed to the method. In this case, the hash is regenerated when one of the following files changes:

vite.config.js
package-lock.json
tailwind.config.js
resources/** (any CSS, JavaScript or Blade template file)
vendor/filament/**/*.blade.php (any Blade templates provided by Filament. We use a custom theme)

The generated cache is stored for 90 days on GitHub servers. If we would start adding Tailwind CSS classes in more places that are not covered in this list, we can just extend the list of files passed to hashFiles(). Easy-peasy.

Note that we cache the content of public/build/*. If your app would rely on code inside node_modules/ you might have to still run npm ci on your server or find a different solution.

The entire GitHub Actions workflow now looks like this.

name: Deploy

on:
  repository_dispatch:
    types: ['deploy']
  workflow_dispatch:
    inputs:
      deploy_env:
        description: 'Environment'
        required: true
        default: 'stag'
        type: choice
        options:
        - stag
        - prod

  deploy:
    name: Deploy
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: '8.3'

      - uses: ramsey/composer-install@v3

      - name: Frontend Assets Cache
        uses: actions/cache@v4
        id: frontend-assets-cache
        with:
          key: frontend-assets-${{ hashFiles('**/vite.config.js', '**/package-lock.json', '**/tailwind.config.js', '**/resources/**', '**/vendor/filament/**/*.blade.php') }}
          path: public/build/*

      - uses: actions/setup-node@v4
        if: steps.frontend-assets-cache.outputs.cache-hit != 'true'
        with:
          node-version: 22
          cache: 'npm'

      - name: Install Dependencies
        if: steps.frontend-assets-cache.outputs.cache-hit != 'true'
        run: npm ci

      - name: Production Assets Build
        if: steps.frontend-assets-cache.outputs.cache-hit != 'true'
        run: npm run build

      - name: Deploy
        uses: deployphp/action@master
        with:
          private-key: ${{ secrets.DEPLOY_KEY }}
          known-hosts: ${{ secrets.KNOWN_HOSTS }}
          dep: deploy ${{ github.event.inputs.deploy_env }} -v

Updating Deployer to upload the Assets #

The last remaining step is to tell deployer to upload the cached assets to our server. For this I've added a upload:vite-assets task and referenced it in our deploy-task.

<?php

task('upload:vite-assets', function () {
    // Check if the public/build directory exists
    runLocally('test -d public/build/');

    // Upload the assets if they exist.
    upload('public/build/', '{{release_or_current_path}}/public/build/');
});

desc('Deploy application');
task('deploy', [
    'deploy:prepare',
    'deploy:vendors',
    'upload:vite-assets', // ← our new task
    'artisan:storage:link',
    'artisan:view:cache',
    'artisan:config:cache',
    'artisan:route:cache',
    'artisan:view:cache',
    'artisan:migrate',
    'artisan:horizon:terminate',
    'deploy:publish',
    'php-fpm:reload',
    'artisan:cache:clear',
]);

When we now deploy our app using GitHub Actions, Actions will restore our public/build/ directory if a cache exists, or it will install our NPM dependencies and create a new build and cache that build.

Deployer will then double-check if the public/build/ directory exists and will upload the files to our servers.

Wrapping Up #

We're really happy with this solution. It allows us to keep everything deployment related inside the GitHub Actions universe.

In addition, it allows us to easily upgrade the used Node version by changing node-version in the workflow. We now don't need to install Node on the server the app is being deployed to and don't have to care about upgrades.

And the biggest benefit is faster deployments. This change shaved off 1 to 2 minutes of each of our deployments. Other CI workflows don't rely on the frontend assets, but if they would, I would add the same steps to those workflows as well.

Reply to Stefan

How I use Shiki in Eleventy

2024-06-03T21:00:00Z

When I migrated to Eleventy one crucial feature I wanted to keep was the server-rendered code blocks.

In the Laravel version of my site, I used the spatie/laravel-shiki package for this, which was a wrapper around the Node binary of Shiki. As Eleventy is already running in JavaScript, adding Shiki to the build was quite easy.

Thanks to this great post by Raphael Höser, I got Shiki running in less than 15 minutes.

The perfectionist I am, I noticed that the cold-start of running Eleventy took a bit longer: instead of 0.5 seconds it took 3 seconds to boot the Eleventy dev server.

I can see you – dear reader – rolling your eyes at what seems like an insignificant delay.
The three seconds to start the dev server is still quite fast compared with the many other static site generators out there.
But still, I wanted to find a solution, that adding more and more posts with code blocks doesn't increase the boot time of my Eleventy instance further.

So I've added a caching layer to my Shiki-plugin using flat-cache.
The plugin now looks like this.

import {createHash} from 'crypto';
import flatCache from 'flat-cache';
import {resolve} from 'node:path';

export default async function (eleventyConfig) {
  // empty call to notify 11ty that we use this feature
  // eslint-disable-next-line no-empty-function
  eleventyConfig.amendLibrary('md', () => {});

  eleventyConfig.on('eleventy.before', async () => {

    const shiki = await import('shiki');
    const highlighter = await shiki.getHighlighter({
      themes: ['github-dark', 'github-light'],
      langs: [
        'html',
        'blade',
        'php',
        'yaml',
        'js',
        'ts',
        'shell',
        'diff',
        ],
    });

    eleventyConfig.amendLibrary('md', function (mdLib) {
      return mdLib.set({
        highlight: function (code, lang) {
          const hash = createHash('md5').update(code).digest('hex');
          const cache = flatCache.load(hash, resolve('./.cache/shiki'));
          const cachedValue = cache.getKey(hash);

          if (cachedValue) {
            return cachedValue;
          }

          let highlightedCode = highlighter.codeToHtml(code, {
            lang: lang,
            themes: {
              light: 'github-dark',
              dark: 'github-dark',
            }
          });

          cache.setKey(hash, highlightedCode);
          cache.save();

          return highlightedCode;
        },
      });
    }
    );
  });
}

The code is very similar to Raphael's solution. The big difference is that in my markdown highlight-function, I generate a hash value of the to be highlighted code. This hash acts as the cache key. If the cache is a hit, the cached value is displayed. If the cache is a miss, Shiki will highlight the given code block and store the value in the file cache.

This caching mechanism reduced Eleventy's boot time back to 1 second.^[1]

I'm sure the file-cache is now the bottleneck and a in-memory cache driver like Redis would bring down boot time even more. But let's keep things simple. ↩︎

Reply to Stefan

Incremental Backups with Borg Backup

2024-05-25T21:00:00Z

When I redid my personal folder structure and moved to iCloud Drive in 2023, I also needed a new backup solution.

Previously, I stored my personal files on my Synology NAS and its data was – and still is – regularly backed-up to a cloud provider and to local hard drives.

By changing my primary storage location to iCloud Drive, creating a backup got a bit more complicated:

For one, iCloud Drive is only available on Apple devices or on Windows. As far as I know, it's impossible to install an iCloud Drive client on a Synology NAS or a Linux server.
When "Advanced Data Protection" is enabled, accessing my iCloud data is even more restricted, as all data is end-to-end encrypted.
The MacBook Pro I own doesn't have the storage capacity to hold my entire iCloud Drive content locally. The 400GB I currently store in Apple's cloud doesn't fit on my 256GB MacBook Pro disk.
There is no SDK or web API available to interact with iCloud Drive. (Probably wouldn't have helped me, as I have Advanced Data Protection enabled)

As it's impossible for me to keep an offline snapshot of my iCloud Drive on my MacBook Pro, it became quickly clear, that I won't be able to create regular backup of all my iCloud Drive data.^[1]
I decided that I therefore only regularly back up my most important files. In my private note on this project I wrote:

The definition of "most important files" is quite hard. For me I consider all the files in the folders 10-29 as most important. The folders contain all personal and financial information from the last 2 decades. If I would lose them, life would become complicated quickly.^[2]

Given iCloud Drive's limitations, I set these goals for my backup software search:

end-to-end encryption: only I should be able to see the contents of my files in the backup.
fast: creating a backup should not take hours
cheap: a one time purchase; not a monthly or yearly subscription
incremental backups: to preserve disk space, the software shouldn't back up all files whenever a new backup is created. Only the changed files should be copied.
files need to be able to be restored without relying on third party applications on third party hardware^[3]

With this out of the way, the search began.

The beginnings with rsync #

At first I've used rsync to create incremental backups.

I used the following script to create incremental backups of my "Personal Documents" folder.

#!/bin/sh

src="~/iCloud/Documents/10-19 Personal-Documents/"

# Path to folder for backups
# Note: ULDUAR is the name the USB SSD where I would store my backups.
dest='/Volumes/ULDUAR/Backups/';

# Set the retention period for incremental backups in days
retention=30

# Start the backup process
rsync --archive \
--delete \
--backup \
--inplace \
--recursive \
--verbose \
--exclude=.DS_Store \
--backup-dir=${dest}/increment/`date +%Y-%m-%d-%H%M`/ \
"${src}" \
${dest}/full/

# Clean up incremental archives older than the specified retention period
find ${dest}/increment/ -mindepth 1 -maxdepth 2 -type d -mtime +${retention} -exec rm -rf {} \;

This system met a few of my requirements: cheap, fast, incremental backups and restoring files does not require third party software on third-party hardware.

But it was finicky. My prior knowledge of rsync was limited to using it as a deploy-tool and debugging the script was a bit of a nightmare.

My attempt to automate the running of the script using launchd was also a failure. Somehow macOS doesn't allow a scheduled script to copy files from the internal hard disk to an external drive. The script always failed with rsync: [sender] opendir "/path/to/destination" failed: Operation not permitted (1).

End-to-end encryption was also not yet solved. I've used this system, while I continued my search for a perfect match, so that I at least got a backup of my files.

Borg Backup #

After many hours of research and reading too many Reddit threads I've landed on my current solution: Borg Backup or Borg for short.^[4]

After creating several proof of concept script to test different backup strategies, I created several scripts in a ~/bin/borg-backup/ -older that now do all the heavy lifting of backing up my files.

`config.sh` #

At the core sits the config.sh file which contains helper functions and config values. Here is an abbreviated version of the file. I use the 1Password CLI to get the passphrase for the backups.

#!/bin/sh

# ...

# Secrets
# ---------------------------------------------------------------

# Setting this, so the repo does not need to be given on the commandline:
# export BORG_REPO=ssh://username@example.com:2022/~/backup/main
export BORG_REPO='/Volumes/ULDUAR/Backups/Borg Repositories/iCloud Drive'

# Extract Passphrase from 1Password item
export BORG_PASSPHRASE=$(op item get <1password-id> --fields label=password);

# Utilities
# ---------------------------------------------------------------
colorOutput() {
    local color="$1"
    local content="$2"

    # Color mappings
    local default="\033[0m"
    local red="\033[31m"
    local green="\033[0;32m"
    local yellow="\033[0;33m"
    local cyan="\033[0;35m"
    local magenta="\033[0;36m"

    printf "${!color}$content$default"
}

printDefault () {
    colorOutput "default" "$1\r\n"
}

printInfo() {
    colorOutput "cyan" "$1\r\n"
}

# ...

`backup.sh` #

The other core script is obviously backup.sh which creates the backup. I didn't write all of this on my own. I think the basic structure is available in the Borg docs.

#!/bin/sh

# source config.sh
source "$(dirname "$0")/config.sh"

printSection "Starting backup"

# Backup the most important directories into an archive named after
# the machine this script is currently running on:

borg create                                \
    --verbose                              \
    --filter AME                           \
    --list                                 \
    --stats                                \
    --show-rc                              \
    --compression lz4                      \
    --exclude-caches                       \
    --exclude '/Users/stefan/.cache/*'     \
                                           \
    ::'{hostname}-{now}'                   \
    '/iCloud/Documents/00-09 INBOX' \
    '/iCloud/Documents/10-19 Personal-Documents' \
    '/iCloud/Documents/20-29 Finances' \
    '/iCloud/Notes' \

backup_exit=$?

# If available, copy the Borg Repositories from the ULDUAR drive (SSD)
# to the NAS. The "Backups" directory on the NAS is regularly
# being backed up to different locations.

if [ -d "/Volumes/NAS/Backups/" ]; then

    printInfo "🟢 Copy Repository to NAS"

    rsync --archive \
    --protect-args \
    --verbose \
    --recursive \
    --exclude=.DS_Store \
    --delete \
    '/Volumes/ULDUAR/Backups/Borg Repositories/' \
    '/Volumes/NAS/Backups/Borg Repositories/'

else
  printCaution "⚠️ NAS not available. Backup not mirrored to NAS."
fi


# Use the `prune` subcommand to maintain 7 daily, 4 weekly and 6 monthly
# archives of THIS machine. The '{hostname}-*' matching is very important to
# limit prune's operation to this machine's archives and not apply to
# other machines' archives also:

printInfo "🧹 Pruning repository"

borg prune                          \
    --list                          \
    --glob-archives '{hostname}-*'  \
    --show-rc                       \
    --keep-daily    7               \
    --keep-weekly   4               \
    --keep-monthly  6

prune_exit=$?

# actually free repo disk space by compacting segments

printInfo "🗜️ Compacting repository"

borg compact

compact_exit=$?

# use highest exit code as global exit code
global_exit=$(( backup_exit > prune_exit ? backup_exit : prune_exit ))
global_exit=$(( compact_exit > global_exit ? compact_exit : global_exit ))

if [ ${global_exit} -eq 0 ]; then
    printSuccess "🟢 Backup, Prune, and Compact finished successfully"
elif [ ${global_exit} -eq 1 ]; then
    printCaution "⚠️ Backup, Prune, and/or Compact finished with warnings"
else
    printError "🚨 Backup, Prune, and/or Compact finished with errors"
fi

exit ${global_exit}

`check.sh`, `list.sh` and `export.sh` #

There are three other files in my script directory. check.sh runs borg check and checks the repository consistency. list.sh runs borg list to get a list of backups and export.sh runs borg export-tar to extract files from a backup into my ~/Downloads folder.

Running the Backup Script #

Running the script is as easy as typing sh ./backup.sh in a terminal of your choice. In my case, 1Password will also prompt me to authenticate the request to access the encryption passphrase.

I've added a task to my weekly review project in Things, to remind me to create a backup.
As I don't want to open a terminal, navigate to the right directory and run the script (or add an alias for all of this) I've added a custom workflow to Alfred to run the script for me.
All I have to do now is open Alfred and type "borg:backup".^[5]

The Bigger Picture #

The Borg script and the storage on the USB-SSD is – however – only a small piece in a bigger backup strategy system.

As you might have noticed in the backup.sh-script above, the repository Borg creates is also copied to my NAS, if the drive is available. This way, the backups for "Important Docs" is located in 2 locations.

And my NAS is then also independently backed up to 2 different location. This illustrations explains my current backup strategy quite well.

As you can see, different data is stored on different devices and platforms and is backed up in different ways to different locations.

Another important piece in my backup strategy are the yearly photo archives. At the end of each year, I export all photos taken during that year, zip them up and upload them into an AWS S3 bucket.

I've been using this system for over a year now and I'm quite happy with it. It has already happend that I needed to restore a specific file once or twice and the system held up.

For now, I'm quite happy with this system and I will use it for the foreseeable future.

You might ask yourself: "Stefan, why do you have 400 GB of data in iCloud Drive? What is all that stuff?". Fair question. The biggest files are in itself backups/archives. Be it yearly archives of my photo library dating back to 1992, backups of old software I would like to keep or my music library. ↩︎
"folder 10-29" refer to my Johnny Decimal folder structure. ↩︎
For example Synology Hyper Backup is a backup software I use on my NAS. In case of an emergency (say my flat burns down and the NAS is destroyed), I would need to purchase another NAS in order to restore my files. In such a situation, purchasing a NAS and setting it up is not the first thing I want to do, just to access my files. ↩︎
Discovering Borg was quite the challenge as its SEO isn't great. It's headline isn't "backup software" but rather the nerdy term "deduplicating archiver with compression and encryption". ↩︎
I want to give Raycast another try soon. Wonder if I could create a neat extension that would work with my list.sh script. ↩︎

Reply to Stefan

stefanzweifel.dev

Show Remaining Characters in a Filament Text Input

Adding the Indicator #

Laracon EU 2026 Recap

Dan Harrin: “Write better abstractions: lessons from an import system” #

Ryan Chandler: “Handling the unhappy path” #

Tobias Petry: “One billion rows with Laravel“ #

Peter Suhm: “Unblocking your users with AI“ #

Simon Hamp & Shane Rosenthal: “NativePHP” #

Luke Kuzmish: “Effective Code Reviews: What NOT to Do“ #

Joe Tannenbaum: “State of the Frontend” #

John Drexler: “Ship to Production on DAY 1” #

Podcasts 2026

Swiss Specific Podcasts #

Recap 2025

Work #

Personal #

Open Source #

Swiss Laravel Association #

Epilogue #

Introducing laravel-tfa-confirmation

What problem does the package solve? #

How does it work? #

What the package doesn't provide #

Outlook #

Custom session lengths for certain actions #

ConfirmsTwoFactor Contract #

Recap 2024

Personal #

Work #

Open Source #

Epilogue #

On Founding the Swiss Laravel Association

Deployer: Build and Cache Frontend Assets once using GitHub Actions

GitHub Actions Workflow for Deployer #

Updating Deployer to upload the Assets #

Wrapping Up #

How I use Shiki in Eleventy

Incremental Backups with Borg Backup

The beginnings with rsync #

Borg Backup #

config.sh #

backup.sh #

check.sh, list.sh and export.sh #

Running the Backup Script #

The Bigger Picture #

`ConfirmsTwoFactor` Contract #

`config.sh` #

`backup.sh` #

`check.sh`, `list.sh` and `export.sh` #