<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
        <atom:link href="https://mozex.dev/blog/feed" rel="self" type="application/rss+xml" />
        <title><![CDATA[Mozex Labs Blog]]></title>
        <link><![CDATA[https://mozex.dev/blog/feed]]></link>
        <description><![CDATA[Articles about Laravel, PHP, and web development by Mozex.]]></description>
        <language>en</language>
        <pubDate>Tue, 07 Apr 2026 14:00:00 +0300</pubDate>

                    <item>
                <title><![CDATA[5 Laravel Queue Failures That Only Show Up in Production]]></title>
                <link>https://mozex.dev/blog/12-5-laravel-queue-failures-that-only-show-up-in-production</link>
                <description><![CDATA[Your queue works perfectly in local. Every job dispatches, processes, and completes without a hitch. Then you deploy to production with real traffic, real concurrency, and real third-party APIs, and things start breaking in ways your test suite never predicted.
I've been running Laravel queues in production for years across multiple applications. Every failure on this list caught me off guard at least once. Not because the documentation doesn't cover them, but because you don't think about them until they bite you at 2 AM.]]></description>
                <author><![CDATA[Mozex]]></author>
                <pubDate>Tue, 07 Apr 2026 14:00:00 +0300</pubDate>
                                    <category>Laravel</category>
                                    <category>PHP</category>
                                    <category>DevOps</category>
                            </item>
                    <item>
                <title><![CDATA[Use Laravel's route(), url(), and asset() Helpers Inside Markdown]]></title>
                <link>https://mozex.dev/blog/11-use-laravels-route-url-and-asset-helpers-inside-markdown</link>
                <description><![CDATA[I had a Laravel project designed to be white-labeled. Swap an env file, change the domain, and the whole application launches as a completely different product.
The problem was the Markdown files.]]></description>
                <author><![CDATA[Mozex]]></author>
                <pubDate>Mon, 06 Apr 2026 14:00:00 +0300</pubDate>
                                    <category>Laravel</category>
                                    <category>PHP</category>
                                    <category>Open Source</category>
                                    <category>Markdown</category>
                            </item>
                    <item>
                <title><![CDATA[How a Rejected PR Became Laravel Scout Bulk Actions]]></title>
                <link>https://mozex.dev/blog/10-how-a-rejected-pr-became-laravel-scout-bulk-actions</link>
                <description><![CDATA[If you've used Laravel Scout on a project with more than a couple of searchable models, you know the drill. You change something in your toSearchableArray(), and now you need to flush and reimport every model's index. Two commands per model. Manually. One at a time.
On a project with ten searchable models, that's twenty commands to rebuild your search indexes.]]></description>
                <author><![CDATA[Mozex]]></author>
                <pubDate>Fri, 03 Apr 2026 14:00:00 +0300</pubDate>
                                    <category>Laravel</category>
                                    <category>PHP</category>
                                    <category>Open Source</category>
                            </item>
                    <item>
                <title><![CDATA[Why I Built a PHP Client for Anthropic's Claude API]]></title>
                <link>https://mozex.dev/blog/9-why-i-built-a-php-client-for-anthropics-claude-api</link>
                <description><![CDATA[In May 2024, I published the first version of anthropic-php, a PHP client for Anthropic's Claude API. Nearly two years and 370,000+ downloads later, it's the most installed dedicated Anthropic SDK in the PHP ecosystem. This is the story of why I built it, what it can do, and why I think packages born from real necessity tend to be the good ones.]]></description>
                <author><![CDATA[Mozex]]></author>
                <pubDate>Thu, 02 Apr 2026 13:00:00 +0300</pubDate>
                                    <category>Laravel</category>
                                    <category>PHP</category>
                                    <category>Open Source</category>
                                    <category>AI</category>
                                    <category>Anthropic</category>
                            </item>
                    <item>
                <title><![CDATA[My Zero-Downtime Deployment Setup for Laravel]]></title>
                <link>https://mozex.dev/blog/8-my-zero-downtime-deployment-setup-for-laravel</link>
                <description><![CDATA[I've been deploying Laravel applications for over a decade. Started with custom bash scripts. Moved to Laravel Envoy. Then Laravel Envoyer, which worked great for a long time. Eventually moved away from it to Ploi.io so I could manage deployments and servers in one place.
Each tool taught me something the previous one didn't. And the biggest lesson wasn't about tools at all. It was about the small practices around deployment that separate &quot;mostly works&quot; from &quot;actually works every time.&quot;
Zero-downtime deployment is widely available now. Most hosting panels and deployment services support it out of the box. But to get the most out of it, there are practices you need to get right. That's what this post covers.]]></description>
                <author><![CDATA[Mozex]]></author>
                <pubDate>Wed, 01 Apr 2026 01:35:05 +0300</pubDate>
                                    <category>Laravel</category>
                                    <category>PHP</category>
                                    <category>Tutorial</category>
                                    <category>DevOps</category>
                            </item>
                    <item>
                <title><![CDATA[WooCommerce to Laravel Migration: The Parts Nobody Talks About]]></title>
                <link>https://mozex.dev/blog/6-woocommerce-to-laravel-migration-the-parts-nobody-talks-about</link>
                <description><![CDATA[If you've run a WooCommerce store long enough, you've felt the slowdown. Pages take longer to load. The admin panel becomes sluggish. Checkout starts timing out during traffic spikes. You throw caching at it, upgrade your hosting, install optimization plugins. It helps for a while. Then it doesn't.
I've been building with PHP and Laravel for over ten years, and I've migrated production WooCommerce stores to custom Laravel applications. Not as a theoretical exercise, but because the stores hit a wall that no amount of WordPress optimization could fix.
Here's what that process actually looks like, including the parts the generic migration guides conveniently skip.]]></description>
                <author><![CDATA[Mozex]]></author>
                <pubDate>Sun, 29 Mar 2026 20:44:35 +0300</pubDate>
                                    <category>Laravel</category>
                                    <category>PHP</category>
                                    <category>Architecture</category>
                                    <category>WooCommerce</category>
                            </item>
                    <item>
                <title><![CDATA[Which AI Package Should You Actually Use in Laravel?]]></title>
                <link>https://mozex.dev/blog/5-which-ai-package-should-you-actually-use-in-laravel</link>
                <description><![CDATA[Eighteen months ago, using Claude or GPT from a Laravel app meant writing raw HTTP calls or using whatever half-maintained wrapper you could find on Packagist. Today there are four solid options, all actively maintained, all with real download numbers behind them.
I maintain one of them. anthropic-php and its Laravel companion anthropic-laravel have a combined 597,000 installs on Packagist. I've been building and shipping AI features in PHP since before most of these packages existed. So when people ask me &quot;which one should I use?&quot;, I have opinions. They might surprise you.
Here's the honest breakdown.]]></description>
                <author><![CDATA[Mozex]]></author>
                <pubDate>Sat, 28 Mar 2026 17:37:39 +0300</pubDate>
                                    <category>Laravel</category>
                                    <category>PHP</category>
                                    <category>Open Source</category>
                                    <category>AI</category>
                            </item>
                    <item>
                <title><![CDATA[Why I Built My Own Laravel Modules Package]]></title>
                <link>https://mozex.dev/blog/4-why-i-built-my-own-laravel-modules-package</link>
                <description><![CDATA[In late 2023, I was working on a large Laravel project and hit a point where the app/ directory had become a mess. Models, controllers, services, policies, listeners, jobs, notifications, all thrown into flat directories with no logical grouping. Everything related to billing lived next to everything related to user management. Finding anything required memorizing file names instead of following a structure.
I knew the answer was modular architecture. Break the application into self-contained modules where each module owns its models, controllers, migrations, routes, views, and everything else related to that feature. I'd seen this pattern work in other frameworks and it made perfect sense for Laravel.
So I looked at what was available. I tried several packages. None of them clicked.
I started building my own solution inside that project. As it grew and I wanted the same structure in my other projects, I extracted it into an open-source package: mozex/laravel-modules.]]></description>
                <author><![CDATA[Mozex]]></author>
                <pubDate>Fri, 27 Mar 2026 03:38:21 +0300</pubDate>
                                    <category>Laravel</category>
                                    <category>PHP</category>
                                    <category>Open Source</category>
                                    <category>Architecture</category>
                            </item>
                    <item>
                <title><![CDATA[Wispr Flow: Why I Dictate Everything Instead of Typing]]></title>
                <link>https://mozex.dev/blog/3-wispr-flow-why-i-dictate-everything-instead-of-typing</link>
                <description><![CDATA[This is the first post in what I plan to be a collection of tools and software I use regularly. No sponsorships, no affiliate links, no partnerships. Just software that changed how I work, shared because I think you might benefit from it too.
Let's start with the one that had the biggest impact on my daily routine: Wispr Flow.]]></description>
                <author><![CDATA[Mozex]]></author>
                <pubDate>Tue, 24 Mar 2026 14:37:20 +0300</pubDate>
                                    <category>Developer Tools</category>
                                    <category>Productivity</category>
                            </item>
                    <item>
                <title><![CDATA[Fixing Pest Sharding for Modular Laravel Applications]]></title>
                <link>https://mozex.dev/blog/2-fixing-pest-sharding-for-modular-laravel-applications</link>
                <description><![CDATA[When Pest v4 dropped, one feature got my attention right away: test sharding. My CI pipelines were painfully slow, and splitting tests across parallel GitHub Actions runners seemed like the obvious fix.
I upgraded, configured the shards, pushed to CI, and waited.
Every shard ran every test. Shard 1 of 4? Full suite. Shard 3 of 4? Full suite. My &quot;optimization&quot; made things four times worse.]]></description>
                <author><![CDATA[Mozex]]></author>
                <pubDate>Tue, 24 Mar 2026 03:03:04 +0300</pubDate>
                                    <category>Laravel</category>
                                    <category>PHP</category>
                                    <category>Testing</category>
                                    <category>Pest</category>
                                    <category>GitHub Actions</category>
                            </item>
                    <item>
                <title><![CDATA[My Claude Code Status Line: Usage, Pace, and Context at a Glance]]></title>
                <link>https://mozex.dev/blog/1-my-claude-code-status-line-usage-pace-and-context-at-a-glance</link>
                <description><![CDATA[I've been using Claude Code as my daily driver for a while now. One thing that kept bugging me was not knowing where I stood with my usage limits until I actually hit them. Claude Code has a status line feature that lets you run a custom script and display whatever you want at the bottom of the terminal. I built one that shows me everything I care about in a single line.
Freek Van der Herten wrote a nice post about his own status line showing the repo name and context window percentage. That was my starting point, but I wanted more: rate limit tracking, reset countdowns, and a pace indicator that tells me whether I'm burning through my weekly budget too fast.]]></description>
                <author><![CDATA[Mozex]]></author>
                <pubDate>Sun, 22 Mar 2026 15:41:11 +0300</pubDate>
                                    <category>Claude Code</category>
                                    <category>Bash</category>
                                    <category>Developer Tools</category>
                            </item>
            </channel>
</rss>
