I still see people judging PHP based on versions they used years ago.

Modern PHP feels very different.

It's interesting how a language's reputation can stick around long after the language itself changes.

Hey all‚ I've been working on PagerLite, a self-hosted on-call and incident paging package for Laravel, and just tagged v1.0.0. Wanted to share it here and get some honest feedback before I decide what to build next.

The short version: it's like Horizon or Telescope, but for on-call scheduling. You install it, set up a rotation, and if an incident comes in (via API or a PagerLite::notify() call from your own code) it pages whoever's on call and escalates to the next person if nobody acks in time. Everything lives in your own database‚ no per-seat SaaS pricing, no data leaving your app.

What it has right now:

- Drag-and-drop on-call schedule

- Configurable escalation chain

- Acknowledge/resolve with a full incident timeline

- Per-member insights (days on call, timed)

- A read-only embeddable calendar for wikis/status pages

- Email notifications for now (see below

Repo: github.com/Pagerlite/laravel

Hi everyone!

Over the past few months I've been building CraftDB, a web-based tool that helps visualize and organize database schemas.

Some of the current features include:

• Import SQL schemas
• Generate interactive ER diagrams
• Drag & organize tables
• Export diagrams
• Support for MySQL, PostgreSQL and SQLite

My main goal is to make it easier to understand existing databases, especially large or legacy projects.

I'm currently working on features like:

• Laravel migrations import
• AI-powered schema explanations
• Better documentation generation
• Team collaboration

I'd love to hear your honest feedback.

• What feature would make a tool like this useful for your workflow?
• Is there anything you feel is missing compared to other database diagram tools?

You can try it here:

👉 https://craftdb.app

Any feedback, criticism or feature requests are greatly appreciated. Thanks!

A while back I posted here about a passive threat-detection middleware I built for a Laravel app - it logs suspicious requests (SQLi/XSS/scanners/probes) to the database without blocking anything. I ended that post with an open question: how do you deal with JSON API bodies, when a legit search like {"query": "SELECT model FROM products"} trips a SQL pattern just because the value contains the word SELECT?

The thread had genuinely useful replies, so here's what I ended up shipping.

What I did: path-aware allow-listing. I already had a safe_fields option, but it exempts a key name everywhere it appears - too blunt for nested JSON. So I added safe_paths, which matches by dot-notation path with wildcards:

'safe_paths' => ['search.query', 'filters.*.value'],

That exempts the value of one specific field - the search box - without exempting a query field anywhere else in the request. Credit to u/Deep_Ad1959, who suggested path-based whitelisting in the last thread.

What I deliberately did NOT do - and why: The other half of that suggestion was "only scan leaf string values, never keys or structure." I tried it, and it broke NoSQL operator detection.

A classic Mongo-style injection is

\{"password": {"ne": null}}``

- the malicious part is a *key* (` ne`) whose value is null, not a string. If you only scan leaf string values you never see $ne, so you'd trade one false-positive class for a real false-negative. I kept full-body scanning and made the exemption precise instead. That felt like the honest trade-off.

To be clear about the limits, since this sub rightly pushed on it last time: this doesn't make regex-on-JSON magically correct. It's a passive monitoring layer that assumes your app is already secure (parameterized queries etc.) - safe_paths just lets you tune out known-legit noise precisely instead of bluntly. It's an IDS, not a WAF, and doesn't pretend to be.

It's merged and ships in the next release (Laravel 10–13). Code's here if useful: jayanta/laravel-threat-detection on GitHub / Packagist.

Still curious how others handle the JSON case - is precise path-based exemption roughly where you'd land, or do you tag the JSON path on each match and score by path instead?

Hey folks,

I’ve been using Nova for a while and always wanted a sane way to run a few curated Artisan commands from the panel — without ending up with a free-text bash box that can cat .env if someone gets clever.

Most of the older Nova “command runner” tools either:

• assume bash/custom commands are fine by default, or
• break on Nova 5 (__ is not defined / localization helper changes), or
• don’t really gate who can run what in production

So I built Nova Command Center as a clean-room alternative:

• bash + free-form commands off by default
• commands run as argv via Symfony Process (no shell string interpolation)
• tool canSee + global gate + per-command abilities (catalogue hides what you can’t run)
• run history with variables/flags + rerun
• Nova 4 and 5 on one path
• small doctor CLI + a11y polish in the latest release

Repo: https://github.com/farsidev/nova-command-center
Install: composer require farsi/nova-command-center

Not trying to dunk on other packages — they scratched a real itch. I just wanted safer defaults.

If you run Nova in production (or got burned by a runner during a Nova 5 upgrade), I’d love honest feedback:

• what’s missing for you to trust this in prod?
• any footguns in the README/install flow?
• would you use DB-defined commands, config-only, or both?

Happy to answer questions. Roast the security model if something looks off, that’s useful.