GitHub - rcsofttech85/AuditTrailBundle: A lightweight, high-performance Symfony bundle that automatically tracks and stores Doctrine ORM entity changes for audit logging and compliance.
https://github.com/rcsofttech85/AuditTrailBundle

https://redd.it/1pt3z8p
@r_php

Why Is There So Little Laravel Content on YouTube?

This might annoy some people, but I keep noticing it.

Laravel is huge. Plenty of serious apps running on it. But when you go on YouTube, it feels almost empty unless you are watching something from the Laravel team.

Search Laravel and you mostly get official talks, release stuff, or very basic tutorials. Same few channels over and over.

Compare that to React or Next. Endless videos. Opinions. Deep dives. People arguing about architecture. People building in public.

With Laravel it feels like everyone just goes to work, builds their app, and logs off.

Why is that?

Are Laravel devs just not into making videos?
Is it because most Laravel work is agency or client stuff that you cannot really share?
Is PHP still uncool enough that people do not want to put their face on YouTube talking about it?

I love Laravel, but compared to other ecosystems, the lack of independent YouTube creators is hard to ignore and probably costs it new users.

Does PHP just not get enough views?

https://redd.it/1pt8qag
@r_php

Why no Elasticsearch support in Forge?

Just wondering if this is a legal issue, maintenance cost, or something else.
Forge supported Meilisearch but not Elasticsearch?




https://redd.it/1pt90o5
@r_php

New Job. Awesome People. Terrible Codebase Management.

I recently started at a new place. And I absolutely love 99.9% of it. My co workers are fun to work with (mainly grey beards who’ve been at it for awhile), my boss is easy going and it’s overall very relaxed. But theres a few small things that just keeps eating at me.

1. They don’t update hardly anything. I’m currently working on a large legacy codebase that was born long before my coworkers started there. Buuuttt, no one has made an effort to clean it up, update it, nothing. It works (barely), but it’s running on PHP 7.4, every dependency version is at an unmaintained level. It’s a giant spaghetti mess with absolutely zero tests. There is no style standard or formatting norm. Not to mention it’s all vanilla PHP with Apache handling the routing. It’s bad.

2. Applications they have built in the last few years in Laravel haven’t been updated since they have been scaffolded. One of which isn’t very large, but still running on Laravel 10. This one also has a slight spaghetti feel to it, but is salvageable.

We are going to be starting a rewrite of the legacy app within the next ~6 months. And I’m getting worried that it’s at risk of being a sloppy build. My lead is already talking about how he wants to restructure the directory layout so it’s “easier to maintain”. He is vehemently against frontend frame works even though a large part of the app would really benefit from client side rendering (registration flows, realtime updating tables, dashboards, heavy data things, etc).

So what I want to know is, how do I start trying to turn the ship in the right direction? My boss seems to really latch on to my ideas and likes my approach to work. But my lead is already trying to shoot down any idea I have (like just sticking to normal conventions).

Any advice on any of these ramblings would be greatly appreciated!!

https://redd.it/1pthtej
@r_php

Simple LLM Tool Calling in Laravel using Prism
https://brice.codes/posts/simple-llm-tool-calling-in-laravel-using-prism.html

https://redd.it/1pti1bt
@r_php

Simple LLM Tool Calling in Laravel using Prism
https://brice.codes/posts/simple-llm-tool-calling-in-laravel-using-prism.html

https://redd.it/1ptiy50
@r_php

Cursor is really good at Laravel. 15.8 billion tokens used and top 0.5% of usage. Most of this is Laravel apps and packages.
https://redd.it/1ptp4y5
@r_php

How to keep an API running for years: Versioning vs Evolution Pattern or another solution ?

Keeping an API working on the long run is a challenge.

Even an API we developed 3 years ago has already received dozens of updates, some of them unrelated to functionality.



To keep it working securely and optimally, we performed:

\- Updates to our dependencies.

\- Performance optimizations for improved response times.

\- Code refactoring.

\- CI/CD and unit tests to check the code.



With all of the above, one issue still remains: how to handle changes to existing endpoints?

Almost anything changed at that level can impact execution for customers.

Adding new parameters might not impact existing implementations, but changing or removing existing parameters will instantly generate errors for API clients consumers.

We brainstormed and researched ways to handle this topic efficiently.

The community mentions terms like versioning, sunsetting, and evolution pattern.

We are leaning more towards evolution pattern because we are convinced that cloning code or managing multiple branches is not sustainable on the long run.

https://www.dotkernel.com/headless-platform/evolution-pattern-versus-api-versioning/


https://api-platform.com/docs/core/deprecations/

Deprecating endpoints or individual properties from an endpoint via sunsetting sounds like the more manageable solution.

It's difficult to be 100% certain at his point, because each project is different and we must adapt accordingly.

We haven't yet worked on APIs that would benefit from versioning.

It feels like versioning fits enterprise-level projects with increased complexity.

How about you guys?

What solution do you use (or prefer) more - versioning or evolution pattern?

https://redd.it/1ptrib5
@r_php

Boost - Laravel supercharged with AI
https://youtu.be/av4TqZVOXLs

https://redd.it/1ptsrai
@r_php

Would love some constructive feedback from anyone that has the time...

So i'm working on a new greenfield project for myself based on modern php that is a full ecosystem, from philisophical methodology & standards / educational content to actual code, composable enterprise capability runtime, marketplace, etc... The ruling philosophy and methodology (brainy stuff more then code) is named 'Buildshido' and I'm basically working on applying 'Bushido' (The samurai code, "Way of the Warrior") to software development, and i'm using buildshido to build 'Shinobi' (composable enterprise capability runtime) and the rest of it's ecosystem. Ultimately hoping that the approach/etc... can replace agile/scrum/etc.. in some intances but at the end of the day i just want to help people create bad ass systems that are better then the ones of days gone past and do something cool w/ it.

I'm copying and pasting the rough drafts of the 'forward' and the 'meet buildshido' pages of my projects docs. If you have the time, please take a quick read and I'd be super grateful for any constructive feedback (not on grammar and the like, but the general concept and what not). I'll be adding more polish/etc... over the next few days in prep for my hopeful jan 1st launch/release so I'm hoping for more of the abstract thoughts/feedback but everythins welcome.

Thanks in advance!

\-----

# Forward

Ok, so you’re here and maybe you’re a little confused. Maybe you purchased this ebook thinking it was about Bushido or The Way of the Warrior and you wanted to be a samurai. If so, sorry about your luck; this ain’t that.

It’s close, though. This is actually Buildshido—which is Bushido applied to software development. It’s a set of best practices, methodologies, and design patterns proven to help build composable, self-evolving, badass software systems that outlast their creator. We directly address the biggest issues bespoke systems face: quickly becoming obsolete/legacy, the inability to keep up with changing business requirements, and the “enshittification” that happens when scope creeps and code becomes a spaghettified nightmare.

Oh, and if you haven’t noticed, the language is a little rough. While I try to keep it professional, we’re adults here and I’m not the best guy for prim and proper presentations. I’m the guy in the trenches, blood up to my elbows as I wade through an ocean of chitin and bug remains after a doomed Friday launch. I’m the one trying to keep production from bursting into flames and our churn below 100% because some FNG decided they could just “wing it,” bypass policies, and push a half-assed hotfix without a basic understanding of how things function.

Here in the mud, in the trenches, shit gets real. As such, I stay real. I keep a 100% no-bullshit approach with directness and honesty that is a hell of a change of pace after a week of meetings full of corporate lingo and buzzword bullshit.

# What the Fuck is This?

If you’re looking for a dry, academic breakdown of Design Patterns or a “Hello World” tutorial for the latest trendy JavaScript framework, put this book down and walk (better yet, run) TF away. You’re wasting your time, and you’re wasting mine. There’s no way that ends well for either of us.

This isn’t a textbook. It’s a manifesto for the survivors, the grinders, and the architects who are tired of building digital landfills for corporate ghouls. It’s a path that will turn you into the type of engineer that doesn’t waste their potential or inflict the anguish of endless rewrites on future generations. This is a philosophy for warriors—the crazy bastards making it happen when everyone else thinks it can’t be done. This is how the real ninjas get shit done.

# The Reality

Most software development is a lie. We’re taught to build rigid, fragile boxes and call it “Enterprise Architecture.” We’re told to follow “best practices” written by people who have never had to keep a server running while their world was falling apart.

Buildshido is about a different path. It’s the intersection

of the Bushido Code and modern, composable, intelligent, self-evolving software. It’s about building systems that don’t just “run”; these systems have the grit to survive, optimize, and eventually, evolve themselves or create entirely new, improved versions of themselves.

# Social Cause: Project BooBoo Personal Dedication

This book and the entire Shinobi Ecosystem is dedicated to Samantha, my Boo Boo. She was the amazing woman who reignited my spark and had her own snuffed out way too soon.

She was my rock. She was the one in the trenches with me when the lights were flickering and the decisions were life-or-death. We didn’t have the luxury of “clean code” or “agile workflows”; we had the raw necessity of survival.

This world could not contain an angel like her. She was taken on December 10th, 2025, from heart failure in her sleep—as I sat a few feet away working on the initial draft of all this.

She was the most generous, kind, and amazing person I’ve had the pleasure of knowing, made of stuff harder than the steel in a samurai’s sword. She showed me what love was when I was unlovable. Her day-to-day followed those core tenets of Bushido in their purest sense: Justice, Courage, Compassion, Respect, Honesty, Honor, Loyalty, and Self-Control.

In an attempt to continue her legacy of helping people, a portion of every cent made from this book or the Shinobi Ecosystem goes to Project BooBoo, a foundation built on “Direct Action.”

No red tape. No corporate overhead. We provide resources to people who are one bad break away from the edge—the people in the trenches who are doing what they have to do to keep their own fire burning. We venture into the mud to help pull out those being eaten alive by it. It is a mission to restore the light lost when the world lost such an amazing soul, trying to do the memory of my beloved BooBoo some measure of honor and justice.

If I can be half as good of a person as she was, I’ll consider my life a success and my legacy secure.

>

Here’s to you, BooBoo!


\-------

# Meet Buildshido

You might be asking how many sleepless nights it took of hard narcotics to come up with the idea of applying the samurai code of Bushido to software development and having a crazy ass idea like Buildshido. The answer is: too many (minus the narcotics—those were baseless allegations!).

The really crazy part of Buildshido is that it works. Sure, it’s not a direct 1-to-1 translation of “How to kick ass as a samurai” to “How to make composable enterprise systems,” however, with multiple decades of development experience in the enterprise arena, I’ve managed to take the ancient code of the Samurai—Bushido—and drag it kicking and screaming into the digital age.

I managed to take those eight timeless virtues (Justice, Courage, Compassion, Respect, Honesty, Honor, Loyalty, and Self-Control) and learn to wield them as the scaffolding for software systems and life.

Let’s keep it real: staring at a list of virtues while your database is shitting itself doesn’t help much if you don’t know what the fuck to do other than trying not to be a POS. That’s where the magic comes in. We don’t worship the virtues; we execute them through a tactical framework I call The Three Gates.

>

# The Three Gates: Acceptance, Attitude, and Action

# 1. Acceptance The Zero-State

This is the entry point. You cannot fix a problem you refuse to acknowledge. Acceptance isn’t about liking your situation; it’s about seeing the “ocean of chitin” for exactly what it is. It’s acknowledging that your code has debt, your server has limits, and your timeline is fucked.

When you stop fighting reality, get your head out of your ass, and see clearly, only then do you have the power to do a damn thing about it. While you are in a useless state of denial, or busy tolerating bullshit you shouldn’t be, you are helpless to actually kick ass. Bathing in the blood of your enemies requires you to first acknowledge where they are standing.

# 2. Attitude The Architect’s Perception

After you accept reality—warts, scars,

and mud included—you have to maintain the right perspective. Your attitude determines whether you drown in the mess or conquer it. In Buildshido, your attitude is the difference between being a victim of “corporate ghouls” and soul-sucking legacy systems, or being the architect of your own reality. By managing our perception of the truth we have accepted, we build the discipline needed to forge our character into a blade that slices through obstacles like hot butter.

# 3. Action The First Strike

Acceptance and Attitude without Action are just high-definition hallucinations. The Samurai didn’t just study the sword; they swung the damn thing. In development, this means writing code. It means producing results. Shipping releases. Making the cut.

Action is taking the messiest, most complex problem and executing the first strike, using your own special flavor of kung-fu to kick its ass into submission. Action is the only thing that moves the needle. Everything else is just talk, and talk is cheaper than happy hour at a two-dollar whore house.

# The Way Forward

Buildshido may be primarily about building software that can evolve, optimize, and outlast you—but these Three Gates are universal. Whether you’re refactoring a legacy monolith, building a self-aware enterprise platform like Shinobi, or just trying to survive the loss of the most important person in your world, mastery of these same tools will see you through the storm.

Going forward, we will go one by one through the 8 principles of Bushido, applying our Three Gates and explaining how they are applied to software architecture, enterprise systems, and the mastery of your own universe.

Be vigilant. Ensure your sword is sharp and your mind is open.

Welcome to the Dojo.

https://redd.it/1ptxtpt
@r_php

Inertia - Best of both worlds
https://youtu.be/Y-QPvD6e1JI

https://redd.it/1pu65r1
@r_php

Custom Collection Methods - Laravel In Practice EP1
https://youtu.be/ZiU1YTZP_g0%0A

https://redd.it/1pu7bli
@r_php

Symfony AI v0.1.0 - First Tagged Release
https://symfony.com/blog/symfony-ai-v0-1-0-first-tagged-release?utm_medium=feed&utm_source=Symfony%20Blog%20Feed

https://redd.it/1pukpjc
@r_php

Help NativePHP reach sustainable open source - Pay What You Want
https://nativephp.com/blog/pwyw-mobile-mini-license

https://redd.it/1pukvc8
@r_php

PHP as a second language after TypeScript (Node)

Does it make sense to learn PHP as a second language for backend development after TypeScript? Or is it better to look at other languages, such as C# or Go?

https://redd.it/1pumqfk
@r_php

True Async RFC 1.7 is coming
https://medium.com/@edmond.ht/true-async-behind-the-scenes-749f90164db8

https://redd.it/1puo9xh
@r_php

Need Help for Learning Next

Hello everyone,

I am an aspiring full stack web developer from Turkey. I've been learning web dev since 2022. I've completed several courses including a private web dev and a phython course in my city. First course consisted of html css js for frontend and php mysql for backend. The second course was mainly about general programming and it was also backend focused with django.

I've also completed a couple udemy courses for frontend and php. I've also completed laracast's php course this year. Also I've started cs50× from Harvard and plan to finish it this year. So my three years have passed learning web dev and programming in general.

Recently, I've had my first job offer to complete an ecommerce web site with shopify by myself.

I am here to ask what should i learn or develop skills for next especially on backend. My options are laravel, wordpress, react with node.js.
I want to learn laravel the most because I've spend so much time learning php.

Is it a safe path to learn laravel and start developing websites with it? My mentor recommended me to learn wordpress first because he said it is easier to maintain and work with it.

He said that it is hard to maintain laravel projects as a freelancer because the website could brake as new updates come and wordpress would be a safer option as it is automatically updated if you choose so.

What do you guys think? I need to hear different opinions.

Thanks.

https://redd.it/1puon1w
@r_php

Symfony AI v0.1.0 - First Tagged Release
https://symfony.com/blog/symfony-ai-v0-1-0-first-tagged-release?utm_medium=feed&utm_source=reddit

https://redd.it/1puz4ea
@r_php

Show HN: Excelentor – Parse Excel/CSV into typed PHP objects with Laravel validation

After hitting a rough patch, I decided to channel my energy into building something useful instead of giving up.

Excelentor is a PHP library that transforms spreadsheets into strongly-typed objects using PHP 8 attributes and Laravel's validator.

What makes it different:

• Annotation-based mapping – no more $row[7] guessing games
• Automatic type casting – strings become ints, dates, booleans automatically
• Laravel validation out of the box – use familiar validation rules
• Lightweight – focused on parsing, not recreating Excel
• (Bonus: demo data features my daughters' names, with creatively adjusted ages 😄)

Use case: Perfect for importing product catalogs, user lists, financial data – anything where you're tired of manual parsing.

Status: v1.0.0 – it works on my machine (and my mom's village). Your bug reports are welcome!

Links: GitHub: https://github.com/shmandalf/excelentor

Packagist: https://packagist.org/packages/shmandalf/excelentor

I'd appreciate any feedback or suggestions. What features would make this truly useful for your workflow?

https://redd.it/1puz9vh
@r_php