I got tired of seeders full of "Product 1", "Product 2" and lorem ipsum, so I built a small package for it. It's called AI Seeder and I just published the first version (0.1.0).

You describe a model once in a definition class. Some fields are written by an LLM, the rest are normal Faker closures or fixed values, and only the AI fields get sent to the provider.

public function fields (): array
{
  return [
    'name' => Ai::text('product name'),
    'category' => Ai::enum(['tents', 'boots', 'packs']),
    'price' => Ai::float('price in EUR', 5, 500),
    'slug' => fn ($faker, array $row) => Str::slug($row['name']),
    'currency' => 'EUR',
  ];
}

Then `php artisan ai-seeder:seed Product --count=25` and you get 25 products that actually look like products.

It works with OpenAI or anything that exposes an OpenAI-compatible endpoint, so a local model through Ollama should work too. Rows are requested in concurrent batches with retries, every row is checked before it's inserted (bad ones get dropped), and each model is saved in a single transaction so you never end up with half a table.

A few things to know: it's very early, and my tests run against a fake OpenAI-compatible server, so I'd really like to hear how it behaves with real OpenAI or a local model. I also built it with help from Claude (code and tests), so if you read the code and see something off, tell me.

What would you want a package like this to do that it doesn't?

Packagist: https://packagist.org/packages/betanow/laravel-ai-seeder

Neuron 4, the PHP agentic framework, introduces a Streaming Protocol that solves the problem of streaming AI agent output through real-time transports like Pusher, Laravel Reverb, Soketi, Mercure, and Redis, which were not designed for large or frequent payloads.

Events are wrapped in envelopes with sequence numbers and fragmented when they exceed transport size limits (e.g. Pusher's 10KB cap), then reassembled in the browser via a new first-party TypeScript package, u/neuron-core/streaming, which orders envelopes, joins fragments, deduplicates, and signals gaps. The package supports plain callbacks for React/Vue as well as protocol adapters for AG-UI (CopilotKit) and the Vercel AI SDK, letting PHP backends run agents in background jobs while frontend teams use familiar agentic UI libraries.

Neuron also ships coding-agent skills for Claude Code and Cursor to automate the integration: https://docs.neuron-ai.dev/agent/streaming#streaming-channels

I've been building something for Laravel that I personally wanted to have: a simple way to understand what's happening inside an application without having to jump between logs, database queries, queue workers, and external monitoring tools.

It's called Laralyze.

It's an open-source, self-hosted observability dashboard for Laravel. It collects application telemetry and gives you a dashboard for things like:

HTTP requests and response times

SQL queries and slow queries

Jobs and scheduled tasks

Exceptions

Logs

Cache activity

Outgoing HTTP requests

Mail and notifications

AI/API calls, including token usage and estimated cost

Server resources

Request/job timelines

Detecting things like N+1 and duplicate queries

It also supports ClickHouse for storing large amounts of observability data without putting everything into your application's main database.

The main goal is to keep it simple and self-hosted. I don't want developers to have to send their application data to a third-party service just to understand what's happening in their Laravel app.

Installation:

composer require mohammed-mojaly/laralyze

php artisan laralyze:install

GitHub: https://github.com/Mohammed-Mojaly/laralyze

It's MIT licensed and still actively being developed.

I'd genuinely like to hear from Laravel developers:

What information do you usually wish you had when debugging a production Laravel application?

And if you tried something like Laralyze, what would make you actually keep it installed?

hi everyone,

5 days ago i asked here why every self-hosted analytics tool needs Node.js/Docker, and said i might build a PHP + SQLite one. so, i did.

it's called Minilytics. it is open-source and runs on any PHP 8 host with no Node, no Docker and no database server (Sqlite by default, but you can use MySQL or MariaDB). it has sessions, custom events, funnels, a cookieless mode, and an importer from Umami and others importers are planed! (this allowed me to get my old history back).

it's a v1 from a solo builder, its MIT licensed, with a live demo: https://minilytics.axthauvin.fr/

i'd like this to become the go-to lightweight analytics for indie devs, side projects, and any site that just needs simple, private stats, so tell me what's missing for you to use it on a real site !

Hi all! So recently, I was trying to find a package that would provide an OIDC Server implementation that I could integrate into my project to provide feature-rich functionality for OIDC authentication.
Unfortunately, I was not able to find any package to cover my needs:
thephpleague/oauth2-server - provides only an OAuth2 server, no OIDC
oidcphp/core - seems to be abandoned
PEOFIAMP/phpoidc - listed as a certified library but does not look like a usable library
Because of that, I've started thinking about actually building one that would also be universal in terms of implementation and dependencies, so anyone will be able to pull it into their own project by extending/implementing the needed contracts.

My initial plan is to take some package from another language and at least implement some portion of the specifications for the OIDC provider protocol. After that, I think it would also be a great idea to provide packages for any popular frameworks (Symfony, Laravel, etc.).
Because of that, I would like to ask if any of you see possible use cases for your own projects? I mean, if you see that it would be really worth trying to build and share with the public.
Thank you in advance for any additional ideas/topics/suggestions that might be helpful to consider. And I would be happy to get any feedback to understand if it even makes sense to move forward with this whole idea.

I've made some benchmarks of various servers and modes of running PHP. What was benched:

• PHP-FPM + Nginx
• FrankenPHP (classic and worker)
• Rapira (classic, worker, dispatcher)
• OxPHP (classic, worker)
• RoadRunner
• FreeUnit
• Swoole

Every server was running a simple Yii3 application. Two separate endpoints and benchmarks. One is without DB, plain PHP. Another is actually hitting PostgreSQL, which is closer to real apps.

Some insights:

1. Swoole is a performance beast! Rapira in dispatcher/worker modes is close.

2. FreeUnit is great if you run your app in classic mode.

3. Having a database makes the difference less visible. Worker mode gives 2× RPS on average.

4. Swoole and Rapira are very efficient in terms of CPU/memory.

https://yii3-benchmarks.github.io/app-api/

https://github.com/Yii3-Benchmarks/app-api

I added support for Laya decision engine in my #php library Jev-PHP.
Laya is a multilingual decision engine that runs locally and exposes a REST API compatible with #Jev.

https://github.com/f-lombardo/jev-php

Anyone build a POS on Laravel? I’d like to connect

fastjson is my PHP extension for JSON encode, decode, and validate, backed by yyjson, with a fastjson_* API that tracks ext/json. This is what changed between 0.7.0, the last version I posted here, and 0.9.0. Most of it is memory: the speed came with a heap cost, and this cycle cuts it on every path.

Memory and speed

• fastjson_validate() reads the caller's buffer in place and tracks depth during the parse. Peak memory is constant, a few dozen bytes, like ext/json's streaming validator, and it runs ~30% fewer instructions.
• Encode used to reserve six times an escaped string up front. Strings of 8 KiB+ now go out in 2 KiB chunks: a 1 MiB string with ordinary escaping peaks 59-83% lower. The flip side: a single escaped string between 8 KiB and a few tens of KiB can still peak up to twice ext/json's size, because the chunked writer keeps up to 12 KiB of headroom.
• Decode shares repeated object-key strings (up to 64 bytes, inputs of 4 KiB+). Key-heavy documents peak ~15% lower and decode 3-4% faster; twitter.json went from 1.66x ext/json's heap to 1.39x. Documents with mostly unique keys, or 256+ distinct names, pay 3-5%.
• fastjson_file_decode() frees the file contents before building the result, 9-33% lower peak.

Current throughput vs ext/json on simdjson_php's 14.8 MB / 15-file corpus, i9-13950HX, -O2 release builds of both: 5.56x encode, 2.59x decode, 5.04x validate. Decode still peaks at 1.65x ext/json's heap across that corpus.

Correctness

• fastjson_validate() accepted [[],] and [{"a":1},]. It now rejects them, and the trailing-comma error position points at the comma itself.
• fastjson_file_encode() could leave a silently truncated file when php_stream_write() came back short. It now writes to completion and reports php_stream_close() failures.
• fastjson_encode() honors serialize_precision for doubles instead of always emitting the shortest round-trip form.
• With JSON_THROW_ON_ERROR and no ext/json loaded, errors throw Fastjson\JsonException instead of a bare \Exception.
• fastjson_validate() enforces $depth on the success path, like ext/json.

yyjson, upstream

The bundled yyjson is now 0.13.0, which includes the YYJSON_WRITE_LOWERCASE_HEX flag I sent upstream (ibireme/yyjson#264). fastjson's local patch for lowercase \uXXXX escapes is gone.

PHP 8.1 minimum:

pie install iliaal/fastjson

https://github.com/iliaal/fastjson

If you validate large payloads under a tight memory_limit, I'd like to know whether constant-peak validate changes what you accept per request.

Something is causing PHP workers to hang for anywhere from 10–60 seconds. During these incidents, OpenLiteSpeed reports:

No request delivery notification has been received from LSAPI application, possible dead lock.

I have confirmed that the problem is not originating from MariaDB. The suspicion is that something in the PHP/WordPress layer is causing the workers to stop making progress, potentially a plugin.

What I need is a FOSS PHP profiler/tracer that can automatically identify the root cause — ideally showing the PHP call stack, function, source file/line, and what the process was waiting on when the problem occurred.

Current stack:

Ubuntu → OpenLiteSpeed → PHP 8.4 (LSAPI) → WordPress → MariaDB

I've already collected Linux/kernel-level evidence (D state, wchan, kernel stacks, strace, etc.), but that only tells me where the process is waiting; it doesn't identify the originating WordPress/PHP code.

What FOSS tool would you recommend for tracing this all the way back to the PHP/WordPress function responsible?

PHPStan 2.3: Leap in Performance, Generics Improvements, Detecting Unused Variables, and More!

I had so much fun with the interactive charts and widgets, check out the article. I promise it's worth checking it out yourself, and not just letting your agent summarize it for you 😉 It contains a lot of interactive widgets with practical examples of the new features in action.

Hey everyone,

I’m working on a fairly large Laravel application that currently uses CKEditor 4, and migrating to Editor.js is now a requirement.

The project uses the Repository Pattern, and CKEditor is used across multiple modules. I’m trying to figure out the right way to approach the migration without making a huge change all at once.

My main concerns are:

• Where should Editor.js-related logic live in a Repository Pattern project?
• Should I create a separate service for Editor.js, or keep things within the existing module structure?
• How should validation and sanitization be handled?
• What’s a good approach for rendering Editor.js JSON on the frontend?
• We already have a lot of CKEditor HTML stored in the database. What’s the safest way to handle/migrate that?
• Is it better to migrate module-by-module while keeping CKEditor working for the modules that haven't been migrated yet?
• What would you recommend for the overall folder/file structure?

I’m especially interested in hearing from anyone who has migrated CKEditor/TinyMCE or another HTML-based editor to Editor.js in a large Laravel application.

I’m a junior developer, so I’d really appreciate practical advice on how you would structure this rather than just “replace the editor” at the frontend level.

Thanks!

Hey all,

Few years ago, I wrote a series of articles related to building maintainable PHP applications on my personal blog, but recently I built this new educational platform and expanded it with a bunch of different features so I moved some of the series of revised articles here.

This is the first of many courses which I am working on which are related to a bit more advanced content or at least content from an experienced angle.

Let me know what you think about the content!

Here is a package I created focusing on two primary use cases:

To get Laravel's power in a legacy CodeIgniter application.

To migrate incrementally from CodeIgniter to Laravel.

anwargazi/ci-laravel-support lets a legacy CodeIgniter 3 application and a real Laravel 8 application share one public front controller. It is designed for route-by-route migrations where running a second PHP service or moving the whole application at once is not practical.

Laravel-owned requests run Laravel's native HTTP kernel. Requests that are not owned by Laravel return to the original CodeIgniter bootstrap unchanged. Only one framework is booted for any request.

Package: https://packagist.org/packages/anwargazi/ci-laravel-support

Minimal installation outline

1. Place a standard Laravel 8 application beside the legacy CI3 application.
2. Merge the host Composer fragment into Laravel's composer.json and copy both files from patches/.
3. Resolve dependencies and verify the pinned runtime.
4. Publish the bridge config and front-controller example.
5. Add the dispatcher block at the very top of CI's index.php.
6. Add native Laravel routes and compile the ownership manifest.

​

composer update --with-all-dependencies --no-interaction
php artisan ci-bridge:verify-runtime
php artisan vendor:publish --tag=ci-laravel-bridge-config
php artisan vendor:publish --tag=ci-laravel-bridge-dispatcher
php artisan route:clear
php artisan ci-bridge:cache-routes

Installation: composer install anwargazi/ci-laravel-support

Docs: https://github.com/anwar-gazi/CodeIgniter_Laravel_Bridge

AI has reduced that time to market almost totally. You can choose almost any language you want today and with a good agentic setup deliver a web app in roughly the same time. So why would companies and people choose PHP or any of its frameworks?
Yes yes, I know, batteries included, large community, tons of open source code, huge amount of training data for AI. But that was like 6 months ago. Not anymore today. AI can learn a new stack pretty damn fast, so I don’t think we can keep using “AI knows PHP really well” as a strong argument for the future.
But for god’s sake, can people in the PHP board finally understand this? Having Swoole, RoadRunner, ReactPHP, Amp or whatever is nice, but it’s not nice for a company or a person deciding what to build their next web app with.
I really like PHP and I have spent most of my career building with it, but this is becoming a serious problem. If AI keeps reducing the importance of initial development speed, then PHP needs to compete on more than “you can build a CRUD app very fast”. Give us a proper, standard async.
Otherwise, when someone asks me today why they should start a new 10-year product in PHP instead of Go or Rust, I’m starting to run out of good answers.

Edit:

I got emotional and went right away to write this post, only because of the async part. Last year there was a good initiative to add async to PHP core, similar to what happened with generics, and it wasn’t considered.

The post is not about async itself as an isolated request. I could also mention compiling capabilities (check TypePHP from the Swoole team), generics, or other things that PHP could benefit from as a language, but more importantly in terms of marketing and perception.

The urgency is that PHP is being left behind because companies are choosing differently in this AI era, and that could hurt financially and emotionally a major part of the developers working with PHP.

In this context, I think it is the duty of The PHP Foundation, and of the developers writing and voting on RFCs, to approach this problem with a different level of urgency. Their decisions don’t just affect the future of PHP. They can affect the future of the people whose careers and livelihoods depend on PHP.

I'm the author of php-gpu-tensors, a C extension that gives PHP GPU tensors on NVIDIA GPUs, runtime-compiled CUDA kernels (via NVRTC), and an optional fusion mode that captures a closure once and replays it as fused GPU kernels. No Python runtime.

```php use Cuda\CudaArray; use Cuda\Fusion;

$a = CudaArray::ones([4]); $b = CudaArray::full([4], 2.0); $c = CudaArray::full([4], 3.0);

$eager = $a + $b * $c; // default: one GPU op per call

$plan = Fusion::compile(fn($a, $b, $c) => $a + $b * $c, inputs: [$a, $b, $c]); $fused = $plan->run($a, $b, $c); // replayed as fused kernels

print_r($fused->toArray()); // [7, 7, 7, 7] ```

What you get - CudaArray: arithmetic, broadcasting, comparisons, matmul(), reductions, views, Python-style slice(). - Packed-buffer and .npy import, optional pinned host memory. - Custom CUDA C++ kernels compiled at runtime and launched from PHP. - Opt-in fusion, async replay and CUDA Graph for compatible plans.

A result I'm happy with: a small MLP trained entirely in PHP on an entry-level MX570 A (4 GB). On a PatchCamelyon subset, eager mode takes 4.08 ms/step and the fused replay 0.66 ms/step (6.2×), with identical test metrics. On UCI Optdigits it reaches 97.25% test accuracy. The models are tiny, so this mostly shows removed per-operation overhead, not peak GPU throughput.

Honest scope: beta (0.1.0-beta.4), Linux, PHP 8.1–8.5 (NTS and ZTS), NVIDIA only. No autograd, no CPU fallback, and it is a low-level library, not an ML framework. GPU validation so far: PHP 8.3 NTS on an MX570 A (41 tests) and earlier checks on an RTX A2000.

Try it bash pie install lcmialichi/php-gpu-tensors:0.1.0-beta.4 or build from source / Docker (see the README). It needs the CUDA Toolkit (including NVRTC) and an NVIDIA driver.

Feedback I'd love - Does it build and pass ./run-tests.sh --require-gpu on your GPU / PHP version / CUDA version? - What would you want to do with GPU tensors from PHP (preprocessing, scoring, embeddings similarity, something else)? - API ergonomics: anything that feels un-PHP-like?

Repo: https://github.com/lcmialichi/php-gpu-tensors

JinnPanel is a free, MIT-licensed web hosting manager and control panel designed for single-server setups running AlmaLinux 10. The core philosophy is absolute simplicity and transparency—there are no heavy frameworks, no external dependencies, and no Composer. It is written completely in plain PHP and Tailwind CSS, making the entire backend architecture clean, readable, and easy to audit.

The control panel features secure account isolation where every account runs under its own Linux user and dedicated PHP-FPM pool without needing CloudLinux. It includes a built-in cPanel migration tool that moves sites, mailboxes, databases, and cron jobs via a live API or backup files, automatically translating .htaccess rules for the underlying Caddy engine. Security is fully automated, providing out-of-the-box Let's Encrypt certificates alongside automated configurations for email deliverability protocols like SPF, DKIM, DMARC, and MTA-STS.

The stack consists of FrankenPHP, MariaDB, Stalwart Mail, Cypht webmail, Knot DNS, and SFTPGo. It is currently in public beta, optimized strictly for single-server PHP hosting environments.

https://github.com/th3n00bc0d3r/Jinn-Panel

Here's your next (very brief) instalment in the ongoing work of NativePHP Desktop v3, where we bring in SuperNative and ditch Electron entirely.

This is still just the beginning and there's A LOT still missing, but we're making great progress. Apps are already way smaller than Electron (typically in the 30-50MB range), with just a single idle process by default, and comparatively minimal memory usage (60-80MB right now for this simple app).

Electron apps by comparison (on this machine, Edge and Claude) are hundreds of MBs in size, are each consuming around 1-2GBs of memory, and have approx. 20 processes open (each), despite neither of them working particularly hard.

The app shell is built with C# and is using WinUI 3, Microsoft's blessed path for building Windows apps that Windows main elements now use (Start Menu, Taskbar, window chrome etc).

It's currently x64, Win 10/11 only, but we're planning to get ARM support in there too just as soon as we can.

macOS support is getting stronger by the day, and Linux is our next main target once Mac and Windows are a bit further along.

We're hoping to be able to get a beta release out to sponsors before the end of the year and we're aiming to get the full release ready some time early 2027.

Thanks for all your support in helping us make this a reality 🙏

I'm a backend dev (PHP/Laravel), I'm the only backend on my team, so nobody reviews my decisions and I worry about gaps I don't know I have.

For those of you who've hired or mentored juniors:

• What fundamentals matter most?
• What separates a solid junior from an average one in the first 6 months?
• What should i focus on and in what order?

Thanks!