At work, I kept writing the same thing: a few analytics tables, a cron job to rebuild them, and the same SQL copy-pasted into three models. Change one definition, forget to update one copy, and suddenly two dashboards quietly disagree.

There’s `dbt`, which solves this problem for data teams, but it means bringing Python and a second toolchain into a Laravel project. So I tried the same idea in PHP.

An analytics model is an Eloquent model with one query on it:

```php
class Revenue extends Model implements AnalyticsModel
{
use Analytics;

public function computes(): Query
{
return $this->from(Order::class)
->where('status', '<>', 'cancelled')
->per('customer_id')
->measure('total', 'sum(amount)');
}
}
```

Then `php artisan analytics:sync` works out what depends on what and builds everything in the right order.

After that, it’s just Eloquent:

```php
Revenue::query()->where('total', '>', 1000)->get();
```

A few things it does:

* The `GROUP BY` comes from the dimensions you declare, so you never have to write them twice.
* it has Incremental, microbatch, and snapshot buildsthe, same ideas as dbt.
* Runs on PostgreSQL, MySQL, and SQLite with the same commands.

### What it does not do

Every model in a dependency chain has to use the same connection.

That means you can’t, for example, import a SQLite query directly into a PostgreSQL query. This could be solved with an import mechanism, and I am still thinking about a better way to make that work in an Eloquent-like way.

### Why not just use a query class with dependency injection?

A query class, like the action pattern in `App\Queries`, that you inject wherever you need it is perfectly fine.

If the aggregate is fast, you need live numbers, and you only have one or two of them, write the class and skip this package.

The issue is that it computes on every read and you have zero indexes.

Cache the query? Now you’re stuck dealing with stale data.

There’s another problem: each layer (CTEs, subqueries, etc.) gets re-run instead of being reused.

You can use query classes can be composable by calling each other, but a shared subquery is still recomputed inside every caller. This package composes by reference.

For example, you can have a `StgOrder` model representing a transformed version of the `Order` table. It gets built once, and the models that depend on it simply select from the finished table.

This package can append the rows that arrived since the last run, rebuild one day at a time, or keep one row per version with `valid_from` and `valid_to`.

This package will make a built table that can carry the indexes your read patterns need.

A helper like `Revenue::isStale()` can tell you when the data has passed its freshness window.

### Why not just write a job that rebuilds the table?

That’s essentially what the package does.

The difference is that the queries are reusable, and dependencies are propagated through the entire chain of downstream aggregates.

TLDR; You write reusable queries as a data person but in PHP.

Repo: https://github.com/eznix86/laravel-analytics

Read more about DBT: https://en.wikipedia.org/wiki/Data\_build\_tool

the real dbt guys: https://github.com/dbt-labs/dbt-core (for the curious folks)

If you're working with Laravel 12 and want to implement proper roles and permissions, I put together a complete tutorial using Laravel Breeze + Spatie Laravel Permission.

In the video, I cover:

Laravel 12 + Breeze authentication setup Installing and configuring Spatie Permissions Creating Roles & Permissions Assigning permissions to users Checking roles and permissions Protecting routes with middleware Role-based access control Practical examples with Admin / Manager / Employee roles

🎥 Full tutorial: https://youtu.be/vX46YQprMho Language:Hindi

Hope this helps anyone currently implementing RBAC in Laravel.

Hi everyone,

I work for a Brazilian federal university, and we're starting to plan a new integrated system that will serve the whole university community (from teaching-related services to internal administration). Expected usage is high (many requests across several domains), and the system needs to last many years.

One challenge specific to our context: being public sector, we have high staff turnover on the dev team, so whoever joins later needs to ramp up quickly.

We were initially leaning toward microservices, mostly to keep things scalable and modular over the long run, but after reading some older threads here I'm second-guessing that. Given a small-ish team, high turnover, a long lifespan, and multiple domains, would you recommend starting with a well-structured modular monolith instead of going straight to microservices?

And if microservices do make sense for a project like this, which PHP frameworks/tools would you suggest for building the actual APIs: Laravel, Symfony, Slim, Lumen, something else?

Genuinely trying to learn from people who've been through this. Any experience, even 'don't do it', is welcome!

I'm parting with my ElePHPant collection after 13 years of collecting them. I'm raising money for my startup and also will need open heart surgery in the next 5 years. As the UG leader of PHP Vegas for over 10 years, its been a hell of a run. I still love PHP and my startup is built in it, but I also need funds as I'm quitting my full time to do all this. If we crossed paths before, thank you for all the fish. You can find my collection for sell here: https://www.ebay.com/sch/i.html?_dkr=1&iconV2Request=true&_blrs=recall_filtering&_ssn=pokemastercenter&store_cat=0&_nkw=elephpant&store_name=pokemastercenter&_oac=1

Germany is spending €108 million to move its federal websites onto a TYPO3-based platform. The European Commission runs 770 sites on Drupal. Around 300,000 German federal users work on Nextcloud. All PHP.

Across Europe, when governments say "digital sovereignty," what they're describing is very often a PHP application. In our latest blog post, Sebastian Bergmann looks at where PHP runs in the public sector, why so little of that support reaches the maintainers underneath it, and three practical changes to procurement that could fix it.

Building a Filament plugin with several admin pages. Wrote them with Tailwind utilities. Looked perfect locally, completely unstyled on a fresh install.

Obvious in hindsight: Tailwind generates only the classes it finds in configured content paths. A host app doesn't scan your vendor package's Blade files, so your utilities never get compiled. My dev panel scanned everything, which is why I didn't catch it.

The documented answer is to have consumers register a custom theme and add your package path to their Tailwind config. That's a build-step dependency you're imposing on everyone who installs your package, plus a support channel full of "did you run npm run build".

What I did instead: rebuilt on the framework's own components, plus a small hand-written stylesheet using the framework's CSS custom properties (`var(--gray-950)` rather than hex). That gets light mode, dark mode, and custom palettes for free. It's inlined once per process via a render hook, no asset publishing, no build step.

Then a test that fails if a utility class shows up in any package Blade file, because otherwise future me will absolutely reach for `text-sm`.

Genuinely curious what others do here. Ship a compiled CSS file? Require the theme? Avoid custom UI entirely?

We moved off Docker Desktop to Colima ahead of the licensing changes. The migration was supposed to be boring. Then PHP-FPM started dying with exit code 139 (SIGSEGV) about a second after start — no logs, no core dump, no error. PHP CLI was fine, six thousand unit tests passed. Only the FPM master crashed.

The cause, three layers down:

• OPcache asks the kernel for huge pages when its shared memory size is a multiple of 2 MB — mmap() with MAP_HUGETLB.
• Docker Desktop's kernel rejects that cleanly, and OPcache just falls back to normal memory. Nothing to see.
• Colima's kernel has huge page support compiled in. It starts the mapping, unmaps the old range, and then fails with ENOMEM. A correct kernel should never do this — a failed mmap() is supposed to leave the old memory untouched.
• Under Rosetta 2, that hole isn't empty. The process touches it and dies.

The fix: a seccomp profile that returns EPERM for any mmap() carrying the huge-page flag — the same clean "no" Docker Desktop's kernel already gives. Two rules on top of Docker's default seccomp profile, applied machine-wide in colima.yaml, so there's no need for per-repo overrides.

A few things that do not help, in case you go looking: JIT settings, vm.overcommit_memory, ASLR. Enabling huge pages properly inside the VM is a trap too — php-fpm stops crashing and starts hanging instead, which is arguably worse.

Full write-up with the seccomp profile, a two-line curl+jq snippet that builds it from Docker's default, and the smaller escape hatches (opcache.memory_consumption=65, preferred_memory_model=shm):

https://blog.crazy-goat.com/en/colima-php-fpm-segfault-exit-139/?utm_source=reddit

Hi folks! Last year I started an initiative at PhpStorm to sponsor around 5 open source projects for a year. The first year has almost come to an end, and so I'm looking for 5 new projects to sponsor.

So I'm doing an open call to anyone who wants to nominate an open source PHP project they think is worth sponsoring. It could be large, it could be small, it could be something you built yourself. The only criteria is that it is open source and not a commercial product itself; and that it has something to do with PHP.

Just for reference, this was last year's announcement: https://www.reddit.com/r/PHP/comments/1nwd6hs/moving_php_open_source_forward/

An article about a defensive, framework-neutral PHP implementation of Apple Sign in with bounded JWKS fetching, modern JWT verification, full OAuth lifecycle support.

I recently reviewed a PHP application whose Sign in with Apple flow depended on an old library. The package had helped many developers, but its implementation reflected a different time in the PHP ecosystem. It included a frozen copy of JWT code and downloaded Apple’s public signing keys during every login using an unbounded network call. Hoping this article and repo would be useful to someone implementing apple sign in with php

github repo - https://github.com/binuka200/apple-sign-in-php

As Roman Pronskiy's term on The PHP Foundation Board comes to an end, he is replaced by the wonderful Brent Roose, from a unanimous vote. Welcome Brent! 🚀 And thank you for your years of dedication and commitment to The PHP Foundation, Roman! ❤️🐘

Last year I shared PHPStreamServer here.

PHPStreamServer is an event-loop-based application server and process manager built entirely in PHP. It brings HTTP serving, worker supervision, scheduled tasks, logging, and metrics into a unified runtime.

Applications remain loaded between requests, with asynchronous execution powered by Revolt event loop and AMPHP.

I've been quiet publicly since my last post. During that time, I've continued using it as the primary runtime for my personal projects and improving it based on the experience. I've now released version 0.9, the project's biggest update yet.

One of the biggest architectural changes in 0.9 is that PHPStreamServer now requires FFI. This allows it to call native OS APIs directly for capabilities such as Unix-socket peer credential verification, parent-death signaling, and native file monitoring.

Some highlights:

• Workers and scheduled tasks can now be registered and removed dynamically at runtime.
• Message-bus commands are now a public API, allowing workers to send requests directly to the master process, for example, to start or stop on-demand workers dynamically.
• The Unix-socket message bus was redesigned with security as a major focus. It now validates peer credentials and enforces source authorization, preventing unprivileged local users from managing a server running under a privileged account. Deserialization is also restricted to reject unsafe payloads.
• File monitoring now uses native inotify on Linux and FSEvents on macOS, with polling as a fallback.
• On Linux and FreeBSD, workers now use OS-level parent-death signaling, so they terminate instead of continuing as orphaned processes if the master process crashes or is killed.
• Daemon startup now waits for the master process to initialize before reporting success.
• Worker startup, shutdown, crash reporting, and log delivery are now more reliable.
• The supervisor now reports non-zero worker exits and termination by operating-system signals.
• The scheduler now supports named weekdays and months, presets such as @daily, and uses fractional-second delays for more accurate execution.
• The public API now uses consistent worker terminology across all components.
• Console and log output were redesigned to give PHPStreamServer a distinct and consistent visual identity.
• Per-process network traffic monitoring now batches and sends only traffic deltas through the message bus, reducing inter-process communication overhead.

I also refreshed the documentation website with a redesigned landing page. You can check it out here:

Documentation:
https://phpstreamserver.dev/

GitHub:
https://github.com/phpstreamserver/phpstreamserver

Version 0.9 release notes:
https://github.com/phpstreamserver/phpstreamserver/releases/tag/v0.9.0

PHPStreamServer is still experimental and not yet recommended for production use.

I'd especially like feedback from developers working with long-running PHP applications, async PHP, FrankenPHP, RoadRunner, or OpenSwoole. What would you need to see before considering an application server like this for one of your projects?

Sometime ago I was working in a Delivery Management System, we heavily incorporated the Service Repository Pattern to support all the features and capabilities of the system that was launched after 9 months of development and testing (a team of 2 developers, 1 QA tester and a project manager).

I recently started writing an article about this pattern and my opinions about it and I started to think, how would a bigger team preferablly with a software architect would go about reading the scope and coming up with a blueprint, how much architecture is worth building upfront vs overtime?

Article I have been working on: https://blaze64.dev/logs/laravel-service-repository

Join us for The PHP Foundation Community Hour, an interactive podcast that helps you understand how you can contribute to the PHP ecosystem! Shout-out to PHP Architect for providing the infrastructure, platform, and technical support to enable us to host these episodes. 🧡

bun-php allows you to run PHP functions seamlessly in Bun by exposing them as ESM imports. Uses a WASM build of PHP under the hood, no need to install PHP or native deps. Supports Composer and servers. https://www.npmjs.com/package/bun-php

Hi everyone,

I’ve just released the first public version of PHPFlow, an open-source static flow analyzer for PHP/Symfony applications.

The idea came from a problem I regularly run into on larger applications: answering a question like “what actually happens when this route is called?” can mean jumping through a controller, several services, Messenger dispatches and handlers, repositories, database queries and external APIs.

PHPFlow analyzes the source code without running the target application and reconstructs those flows as a graph.

For example, it can help answer:

• What happens when this Symfony route is called?
• Which routes/messages can reach this database table?
• What depends on this service?
• Where is this Messenger message handled?
• Which flows call this external API?
• Where can this exception surface?

v0.1.0 currently understands Symfony routes, dependency injection, Messenger, repositories, Doctrine DBAL/QueryBuilder, external HTTP calls, exceptions and a number of control-flow patterns.

It also generates a self-contained interactive HTML viewer with search, functional lanes, Messenger boundaries, minimap, path-to-effects and critical-path exploration.

PHPFlow is deliberately conservative: if it cannot prove a relationship statically, it doesn’t invent one. It also never boots or executes the application being analyzed.

There’s a bundled Symfony demo, so after cloning:

make setup make demo 

I’m especially interested in trying it against real-world Symfony applications now. If you give it a try and it misses a pattern used by your project, I’d really like to hear about it.

GitHub: github.com/patryyyck/phpflow

Feedback, bug reports and criticism are very welcome.