Mutation Testing with Infection
https://infection.github.io/guide/

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

Supercharge Laravel Development and Apps with AI
https://nabilhassen.com/supercharge-laravel-development-and-apps-with-ai

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

What if we improve the way developers are given access to databases

Adminer, DBeaver, MySQL Workbench, PhpMyAdmin, many developers use those tools every day to get access to databases. The problem ? They use the database credentials to connect to those tools.

What if we could improve that?

https://www.jaxon-php.org/blog/2025/08/what-if-we-improve-how-developers-access-databases.html

The article is also published on Medium.
https://medium.com/p/64cd7e2bef56

Note: built with PHP and Laravel.

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

I built a Centralized MTurk HIT Catcher with PHP + Usernoscripts

I built a small tool to centralize MTurk HIT catching.

\- Paste multiple HIT set IDs into a PHP page

\- Toggle ON/OFF catching via a server

\- Usernoscripts connect to MTurk accounts and auto-accept HITs

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

AWS WAF Firewall rules for a Symfony application

Is anyone aware of a rule set for AWS WAF firewall that would work with a Symfony application?

I know there exists rule sets for a PHP application and a Wordpress application, but there's nothing specifically for Symfony.

Has anyone written or configured there own that they'd be willing to share?

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

Supercharge Laravel Development and Apps with AI
https://nabilhassen.com/supercharge-laravel-development-and-apps-with-ai

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

Ryan Weaver, Symfony core contributor and SymfonyCasts founder and teacher, has passed away.
https://obits.mlive.com/us/obituaries/grandrapids/name/ryan-weaver-obituary?id=59303218

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

Remembering Ryan Weaver: Teacher, Core Team Member, Friend
https://symfony.com/blog/remembering-ryan-weaver-teacher-core-team-member-friend?utm_medium=feed&utm_source=Symfony%20Blog%20Feed

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

I made llama3.2 answer the strawberry question correctly 😆
https://www.youtube.com/watch?v=fbF0buCfwh0

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

simple PHP backend for static webshop (Stripe Elements + SQLite + email invoices)

Hi team, looking for some pointers:
I can do html, css, simple javanoscript and python but I have only edited php.ini in my past.

I'm looking to setup a simple webshop on my vps with the following features:

- (x5) Static HTML product pages + simple PHP backend + Stripe Elements via a static order page (with the stripe iframes).

A simple backend that:

- stores orders in an SQLite file.

- sends invoices from my own configured email.

Any ideas where to start? I can omit the orders database if security is a concern. A large part of this is to avoid Stripe's own hosted checkout/keeping the whole purchasing experience under one domain- with email confirmation included.

I believe this is possible using the Stripe API and webhooks but I have no experience with this and want to use this a reason to learn/get started.

I believe this shouldn't be too hard since I don't need a cart and there are no options on these products. Just "buy it now"s .

Appreciate any guidance!

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

Mago 1.0.0-beta.1 is now available - a new Formatter, Linter, and Analyzer for PHP!
https://github.com/carthage-software/mago/releases/tag/1.0.0-beta.1

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

Symfony 7.3.3 released
https://symfony.com/blog/symfony-7-3-3-released?utm_medium=feed&utm_source=Symfony%20Blog%20Feed

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

Symfony 6.4.25 released
https://symfony.com/blog/symfony-6-4-25-released?utm_medium=feed&utm_source=Symfony%20Blog%20Feed

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

Announcing the Symfony Comic Book
https://symfony.com/blog/announcing-the-symfony-comic-book?utm_medium=feed&utm_source=Symfony%20Blog%20Feed

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

I built a very fast and simple zero-downtime deployment platform for Laravel

Hello everyone,

I’m Henry, the developer of Loupp, which I introduced to this community last year Read here.

Back then, I got a lot of criticism and feedback, which I took to heart. Since then, I’ve rebuilt Loupp, and it now serves 300+ developers with 30+ servers deployed, along with shared hosting.

Many of the issues that were raised have been fixed in v2:

Zero-downtime deployments (I’ll write an article on how this was achieved, if need be).
Improved security: no details are stored on Loupp. Everything is only fetched when you request it, and all data can be deleted immediately by you.
A more intuitive UI (I designed this one personally).
Fast server setup, capped at 4–5 minutes max.
Full documentation.
Server presets – reusable server setup configurations.
SSL uploads.
PHP version switching.

You might ask, “Why build something that already exists?” Well, because I already built it and now I’m taking it on full time.

My goal is for Loupp to focus on linking and unlinking servers in the future: a platform where you can spin up new servers or link existing ones seamlessly, then unlink them whenever you want. A platform for both freelancers and organizations.

Check Loupp out

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

[12.x] Add Ask AI buttons to error page
https://github.com/laravel/framework/pull/56831

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

Laravel Cloud the best option?
https://cloud.laravel.com/pricing

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

Started a open source shopify clone for laravel, drop your comment🚀

⸻

Hi guys, I’m building an open-source ecommerce (like shopify) package for Laravel, since nothing solid exists yet.
Core goals: multi-tenant stores, product & order management, Stripe/PayPal, addons.
👉 Which functionality would you like to see in it?

⸻


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

Tech stack advice needed

Hi there,
I've been working with Drupal for most of my dev career so I know a thing or 2 about Symfony. I have no problems understanding Symfony's backed concepts but I'm a bit puzzled of what's a proper way to build the Front-End part.

My goal is to rebuild a personal Drupal based SaaS using Symfony.
Not because Drupal is not good but because I want to expand my tech knowledge and hopefully in the future land a job around Symfony ecosystem.

I'm basically trying to pick tech stack in between what's used in enterprise(job offers) and my own needs.

The thing is that when I started my SaaS, to satisfy my needs for refresh-less pages, I ported Livewire (Laravel) to Drupal known as "Wire Drupal". In Symfony word this would be "symfony/ux-live-component". I gave it a try, it's usable but I want to go a different route because I would like to build API for my app. Eventually I want to move some API to be served from a Go instance.

Based on my research, looks like this is what I need:
\- Symfony to build backend, API
\- Login, register, homepage, ... served with twig
\- Tailwindcss
\- Interactivity: use a FE framework like Vue or React (can't decide yet - I don't really like React but looks like everyone around using it) as components within templates which would make calls to API.

Now the biggest uncertainty I have is what's a proper way to get Vue/React to work as components?

I'm aware of "symfony/ux-vue" but I'm getting so confused of everything around it, specifically why so many dependencies around like stimulus, turbo; also the choice between Encore, AssetMapper.
It feel like too many dependencies around with unknown feature.

My goal is to have minimum maintenance(especially to the FE part) once built.

Should I just follow everything advised around "symfony/ux-vue" docs or try a different approach?

Thank you.



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

Building a Robust Field Type System for Custom Fields v2

**TL;DR**: Rebuilt the field type architecture from scratch to eliminate boilerplate, add intelligent automation, and provide graceful error handling. Went from 10+ required methods to a fluent configurator API that generates working code in 30 seconds.

# The Problem That Started It All

After maintaining 30+ field types for [Custom Fields](https://custom-fields.relaticle.com/v2/introduction) V1, I kept running into the same issues:

* **Massive boilerplate**: Every field type required implementing 10+ interface methods
* **Manual option handling**: Choice fields needed custom logic for user-defined vs built-in options
* **Fragile system**: Deleting a field type class would crash any page displaying those fields
* **Poor DX**: Creating new field types took hours of copy-paste-modify cycles

The breaking point came when I realized I was spending more time maintaining the field type system than building actual features.

# Design Principles

I established four core principles for the v2 rewrite:

# 1. Convention over Configuration

Smart defaults with clear escape hatches. The system should work perfectly out-of-the-box but allow customization when needed.

# 2. Composition over Inheritance

Instead of rigid abstract classes, use fluent configurators that compose behaviors. This prevents the "deep inheritance hell" problem.

# 3. Fail Gracefully

Production systems can't crash because a developer deleted a field type class. The system must degrade gracefully and continue functioning.

# 4. Generate Working Code, Not TODOs

Commands should create immediately functional code, not skeleton files full of placeholder comments.

# The Architecture

# Configurator Pattern

The biggest change was moving from interface-based to configurator-based field types:

https://preview.redd.it/plv16lxa25mf1.png?width=3680&format=png&auto=webp&s=d3511a3ee6c0b807ecf411f7a429ecb2e55d0f6e

The configurator approach:

* **Encodes best practices**: You can't accidentally create invalid configurations
* **Reduces cognitive load**: Method chaining makes relationships clear
* **Prevents mistakes**: Type-safe configuration with IDE support
* **Enables intelligent defaults**: Each configurator knows what makes sense for its data type

# Intelligent Feature Application

The real breakthrough was solving the closure component problem.

In v1, closure-based components were "dumb" - they only did what you explicitly coded. Class-based components got automatic option handling, validation, etc., but closures missed out.

V2's `ClosureFormAdapter` changed this

https://preview.redd.it/tozdx0r935mf1.png?width=3680&format=png&auto=webp&s=29f92867c1b360d9ec10a37a28909609f81a3e3f

Now developers can write simple closures and get all the advanced features automatically applied.

# Graceful Degradation

One of the biggest production issues was fields becoming "orphaned" when their field type classes were deleted or moved. The entire admin panel would crash with "Class not found" errors.

The solution was defensive filtering at the BaseBuilder level

https://preview.redd.it/jr5h0lp235mf1.png?width=3680&format=png&auto=webp&s=dab99889d373e70c906e806b4f568e9a9f218adb

This single change made the entire system bulletproof against field type deletion.

# The withoutUserOptions() Design

This was the trickiest design decision. Initially, I thought:

* Single choice = built-in options
* Multi choice = user-defined options

But real-world usage broke this assumption. Users needed:

* Single choice with user-defined options (custom status fields)
* Multi choice with built-in options (skill level checkboxes)
* Both types with database-driven options (country selectors, tag systems)

The solution was making `withoutUserOptions()` orthogonal to choice type. It controls **WHO** manages the options, not **HOW MANY** can be selected:

https://preview.redd.it/wix7obsl25mf1.png?width=3680&format=png&auto=webp&s=837733e2b43b175abe0a028e901e5d8ebe1dbb92

This single flag unlocked infinite flexibility while keeping the API

simple.

# Interactive Generation

The generation command showcases the philosophy:

https://preview.redd.it/nxlq3r2o25mf1.png?width=3680&format=png&auto=webp&s=1273d65cc368e40c8712c396f9ca92ab6934dbcd

The interactive prompt shows data type denoscriptions:

* **String** \- Short text, identifiers, URLs (max 255 chars)
* **Single Choice** \- Select dropdown, radio buttons
* **Multi Choice** \- Multiple selections, checkboxes, tags
* etc.

Each selection generates the appropriate:

* Configurator method (`text()`, `singleChoice()`, `numeric()`)
* Form component (`TextInput`, `Select`, `CheckboxList`)
* Smart defaults (validation rules, capabilities)

# Real-World Impact

# For Package Maintainers

* **90% less boilerplate**: field types went from \~200 lines each to \~50 lines
* **Consistent behavior**: Shared configurators eliminated behavioral drift between field types
* **Bulletproof error handling**: No more production crashes from missing field types

# For Package Users

* **30-second field type creation**: Generate → customize → register → done
* **Automatic feature application**: Write simple closures, get advanced features
* **Clear extension patterns**: The configurator API guides you toward best practices

# The Philosophy

The best APIs are the ones that get out of your way. They should:

* **Make easy things trivial** (basic field types)
* **Make complex things possible** (dynamic database options)
* **Make wrong things difficult** (invalid configurations)
* **Make debugging obvious** (clear error messages and graceful degradation)

This field type system achieves all four by being opinionated about structure while flexible about implementation.

# Key Takeaways

1. **Fluent APIs reduce cognitive load** \- Method chaining makes relationships obvious
2. **Automatic feature application** \- Systems should be smart enough to apply features without explicit configuration
3. **Defensive programming pays off** \- Always assume things will be deleted, moved, or broken
4. **Generation > Templates** \- Create working code, not skeletons
5. **Orthogonal design decisions** \- `withoutUserOptions()` works with any choice type because it solves a different problem

Building developer tools is about eliminating friction while maintaining power. This field type system does both.

*Built with Laravel, Filament PHP, and way too much coffee ☕*

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