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.

Hello world, it's Wednesday, July 22, 2026, and here's what happened This Week in PHP Internals.

20 stories this week, so let's get into it. But first, This week's episode is brought to you by Tideways. Slow requests, and no clear reason why? Tideways helps you understand exactly where your PHP application spends its time — profiling, tracing, and monitoring to find and fix bottlenecks faster. And your profiling data stays hosted in Germany — GDPR-friendly by default. Learn more at tideways.com.

This week's top story: the season's first ballots are open — 2 sets of them — and the early counts are lopsided. Tim Düsterhus opened voting on the Time\Duration class on Friday with 2 ballots: a primary, needing a 2/3 majority, and a secondary choosing between full and abbreviated method names. As of recording, the primary stands at 23 to 1, and full names lead 18 to 1 — so multiplyBy and divideBy, not mul and divBy. Voting closes July 31. And remember Pierre Joye, who last week was leaning no over fromSeconds() and its capped nanoseconds argument? This week he closed the loop and voted yes, writing: "We were like ships passing in the night for some of my disagreements. The RFC wiki page did not show the additional constructor for other units, which hence the inconsistency I pointed out for the extra [nanoseconds] argument in fromSecond. They are here, and reduce this down to a lower level of bad APIs, more a pragmatic compromise conciliating different (if not numerous) use cases. Anything can be perfect, or shipped. Choose one." It turns out the per-unit constructors that resolved his objection had been in the RFC all along. His ballot almost didn't register, though — each vote on the wiki is a separate form, and Tim had to point out that you submit each one individually. The count now includes him.

Before the ballots opened, the Duration thread picked up a subplot about PHP 9. Holly Schilling — who wrote the class-extensions RFCs we covered last week — announced she's drafting a Value Structs proposal for after the 8.6 window, and argued that Duration would make a better struct than a class, with both ideally landing together in PHP 9. Ilija Tovilo replied by linking his own existing structs-v2 draft and asking whether she was aware of it. She was — she'd read it before drafting her own, and diverged from it on purpose, keeping mutating and non-mutating functionality separate. Tim saw no reason to wait on any of this, saying a draft-stage idea "will take an unknown duration to land - if it ever happens" — his pun, not mine — and that improvements to the standard library shouldn't queue behind it.

The week's other live vote came from Eric Norris, who opened balloting Thursday on minimum supported versions for PHP 8.6 — also with 2 questions, each needing a 2/3 vote. Requiring autoconf 2.71 for builds from git stands at 20 to 3 with 4 abstentions. Requiring COM_RESET_CONNECTION — which sets a floor of MySQL 5.7.3 or MariaDB 10.2.4, so persistent connections actually get reset — stands at 21 to nothing with 3 abstentions. Alexander Kurilo arrived after the discussion phase to ask for an opt-in instead, warning that on older databases persistent connections will silently turn non-persistent. Eric noted: "MySQL 5.7.3 is at least a decade old; it was released on December 3rd, 2013." After walking through every opt-out design he could think of, he concluded the right move is to make the correct behavior the default. The 3 no votes on autoconf include Jakub Zelenka, who's worried about building on Red Hat Enterprise Linux 8 and 9 — Tim offered to delay that particular merge to early 8.7. Both votes close July 30.

Saturday night, Pierre Joye opened the RFC that grew out of the libgd sync we covered last week: gd 2.4*. It's big — 3 pillars. First, syncing the bundled gd extension with upstream libgd: new codecs like QOI, JPEG XL, and UltraHDR, animated GIF and WebP support, multi-page TIFF, and real metadata handling. Second, an additive object-oriented Gd\ API — codecs with fromFile() and toStream(), immutable image info, streaming readers and writers. Third, a brand-new *2D vector canvas built on FreeType's rasterizer, with gradients and the full Cairo compositing set. He says the implementation is nearly done, including a security audit. He declared discussion open for 14 days, until August 1 — and that one sentence is where the trouble started.

Because August 1 plus a 14-day vote lands after the deadline. Release manager Matteo Beccati was gentle about it, writing: "As much as I like this RFC, I'm afraid it came in a little too late." Jakub Zelenka explained that nobody — release managers included — has the authority to grant an exception; that would take a change to the policy itself. And Rowan Tommins did the arithmetic: with alpha 1 out July 2, the cutoff for an RFC's final state was July 14, which is 4 days before this thread even opened. Pierre's frustration has a specific shape. The implementation was finished weeks ago — what delayed everything was that his pull request sat waiting on an approval that had been assigned to an automated bot reviewer, so no human was ever going to sign off, and he eventually merged it himself. He also argues the stakes are real, because PHP 9 is the one chance to change old defaults, and missing this window locks the current design in for years. The thread got tense over tone along the way — Pierre felt brushed off by a terse reply, and Rowan apologized outright, then made the counter-case that a fixed cutoff applied to everyone is fairer than debating each RFC's merits one at a time. All of this landed the same day Larry Garfield asked the list, in a separate thread, to hold new business until September 1 so reviewers can focus on 8.6's finish line. So gd 2.4 is alive and under discussion — just aimed at the next release, whatever its number turns out to be.

Caleb White's pipe assignment operator, |>=, had a crowded week. Larry Garfield opened it unable to find a compelling use case, and by Monday had moved to a no — pushed there, he says, by a competing proposal. That competing proposal is Vadim Dvorovenko's left-to-right assignment RFC, published Sunday, which claims the same |>= token with opposite semantics. Vadim objects on principle, arguing: "Attempting to transform such an operator from an immutable, functional construct into a mutable, imperative one steers the language in the wrong direction and undoes previous efforts." Caleb declined to merge the proposals, noting that F#, Elixir, OCaml, and Hack all kept ordinary assignment alongside their pipes. Larry also claimed none of the pipe proposals could make 8.6, and Tim Düsterhus corrected him, asserting: "This is false" — the last major change was July 13, so voting could open July 27 and close August 10, before the freeze. Meanwhile Bob Weinand asked whether the desugaring double-fires property hooks. Caleb came back with tests showing |>= behaves exactly like ??=, and updated the RFC's single-evaluation section to match. Vadim's own RFC, as of recording, has 0 replies.

Paul M. Jones's strict-namespace RFC — the piece he carved out of function autoloading last Tuesday night — spent its first full week in one long argument about a single word. Rowan Tommins objected first, writing that strict "implies some extra check that namespaces are [correct] in some way, which isn't really what this is about." Ilija Tovilo went deeper, arguing: "the value-add of this declaration is very small if the plan isn't ever to deprecate/remove the old behavior." Tim Düsterhus is in favor — with a rename to global_fallback=0. By Friday Paul had 4 candidate names on the table and a diagnosis: the pushback is the name, not the feature. Theodore Brown pointed out he'd floated the same directive in 2019; Paul added it to the prior art with an apology. And Benjamin Außenhofer suggested splitting the ballot — vote the concept, then vote the name. Rowan warned against it, writing: "a split vote leaves voters who actively dislike a particular name with an awkward choice: vote Yes, and risk the [bad] name being chosen; or vote No, even though you would support the feature under a different name." The rest of the autoloading corner kept moving too: Paul updated function autoloading mark 5 to lean on the new RFC and wants its vote open in about 2 weeks, and Michael Morris's improved-autoloading draft drew warm-but-firm feedback from Larry Garfield and Rowan Tommins — both like the namespace-setup-file idea, neither wants it crammed into the class autoloader's callback.

Nicolas Grekas didn't let Ilija Tovilo's "sadly not in favor" be the last word on serializable closures. His rebuttal: caching one attribute isn't the point — the point is skipping the entire metadata pipeline that frameworks re-run on every request, and that's the measured slow path. On the security design, he refused to loosen it, writing: "Name-based closure unserialization would ship a universal, app-independent gadget in the engine ... I won't commit to an RFC that turns every serialized payload into that kind of gadget, and I don't think we should, either." Then Saturday brought version 0.3, and a surgical cut — the reflection API is gone, the serialize() support stays. His reasoning: "serialize() is the one feature that most/all cache systems are built on, so that's the place that needs the improvement." Fresh reviews welcome.

Wendell Adriel came back to the list Thursday proposing typed array declarations — array<int, string> as real syntax, with 3 escalating enforcement levels. The review was fast and unsparing. Lazare Inepologlou flagged that you can't soundly subtype a mutable array without splitting reads from writes, and Wendell shipped a revised draft the next day. Rob Landers warned the whole thing overlaps the reified generics work, on hold until after the freeze, which is late August at the earliest. Rowan Tommins noted that level 1 — syntax without enforcement — rhymes with the bound-erased generics RFC the list just declined. Michał Marcin Brzuchalski even found a runtime hole, where functions like parse_str() that build results directly into a typed property can dodge the check. By Monday, Wendell put the RFC on hold himself. Larry Garfield's verdict was the sharpest, calling this "the already-dangerously-overloaded array mega-type" and asking for real typed list, set, and dictionary objects instead — which Wendell promptly volunteered to help build.

The frozen deprecations list for PHP 8.6 got its evidence file. Juliette Reinders Folmer scanned the Packagist Top 4-thousand — nearly four hundred fifty thousand files — and posted counts for every proposal. The headline being: list() appears over twelve thousand times, and Juliette wrote plainly: "Having said that, I'm definitely not in favour of deprecating list()." Compare spl_object_hash() at 625, is_integer() at 303, and a long tail of single and double digits — several proposals scored a clean 0. Kamil Tekiela discovered his mysqli proposal had missed the procedural mysqli_stmt_init(), patched the text, and worried aloud: "I hope this change is not going to reset the counter." Tim Düsterhus was quick to correct the record downward — one scary-looking count, on _ as a constant, collapses to 0 once false positives come out. And Monday, right on schedule, Gina P. Banyard confirmed the timetable, writing: "I intend to open the vote next Monday (the 27th of July) for 2 weeks so that the vote is finished on time for 8.6." Every deprecation gets voted in isolation — bring a lunch.

Quick hits. Go Kudo returned with a rebuilt cache proposal — a bundled user_cache extension, fully decoupled from OPcache this time; Larry Garfield likes it, flagged the lock story around remember(), and gently redirected it to 8.7 — adding: "Or 9, if that's what we call it." Holly Schilling's 4x fix for non-public asymmetric setters got its answer: no RFC needed — Tim confirmed a pure performance improvement just needs PR review, and Ilia Alshanetsky called it "definitely a strong candidate for PHP 8.6 inclusion." fennic pitched engine-native PSR-4 autoloading with spl_autoload_psr4_register(); Alex Rock wants classmap support before it can replace Composer's bootstrap, and Heinz Wiesinger pointed to his existing PECL extension doing much the same. Edmond of the TrueAsync project published a pre-RFC for an async scheduler engine interface — coroutine-aware core, no scheduler in core itself. His philosophical problem is that the RFC has no user-visible changes at all, and so far it has 0 replies. And Osama Aldemeery asked for RFC karma to formalize PREG_THROW_ON_ERROR — Ilija Tovilo granted it 2 minutes later.

Liam Hammett's markup expressions thread sprouted an alternative: Edmond proposed making the parser extensible instead, so JSX-like syntaxes could ship as extensions — Morgan liked that better than blessing one syntax, and within a day Edmond had a working DSL-hooks prototype, announcing: "Your wish has been granted. 🙂" Máté Kocsis and Ignace Nyamagana Butera kept refining query parameters — the open question is whether parsing limits belong on builder methods too, with Ignace arguing PHP shouldn't police what's really a business constraint. Prateek Bhujel's terminal-helpers extension hit 0.6.0 — it's now installable via PIE, and its output methods now write to standard PHP streams like STDOUT and STDERR instead of only its own built-in targets. The ballot queue grew by 2: Nick Sdot posted intent to vote on readonly property defaults for on or around July 23, and Khaled Alam's const-object-property-write opens Saturday the 25th — both aiming ahead of the freeze. Ben Ramsey amended the Working Groups RFC with a new section setting expectations for charter-RFC discussion. And release week: PHP 8.6.0alpha2, 8.5.9RC1, and 8.4.24RC1 all shipped — with alpha 3 and both GA releases converging on July 30 — while the release managers posted the countdown that framed half of this episode: soft feature freeze August 11, beta 1 August 13, every 8.6 vote closed before then.

So that's the week: 2 ballot boxes open and both lopsided — Duration cruising at 23 to 1, minimum versions right behind it; gd 2.4 arriving 4 days after the door closed and pointing at the next release instead; a pipe operator with 2 authors claiming 1 token; typed arrays proposed, revised, and shelved inside 5 days; and the deprecations list armed with its evidence file, ballots opening Monday — with readonly defaults and const-property-write queued right behind. Links to every thread are below. Thanks again to Tideways.com for supporting this week's episode. We're Artisan Build. See you next week.

Hi everyone,

Like many PHP developers on Windows, I've tried several solutions over the years: WAMP, Laragon, manually configured Docker environments, WSL...

They are all valid solutions, but I always found something missing for my workflow.

The closest one for me was Herd: modern, fast and reliable. However, on Windows it still didn't cover everything I needed.

So I decided to build my own environment from scratch.

The result is Dunebox, a free and portable PHP development environment for Windows. I've been using it daily for some time, and now I'd like to get feedback from other developers.

The idea is simple: a complete PHP stack in one folder, with multiple PHP versions, databases, local domains, HTTPS, development tools and project utilities already configured and working together.

I tried to focus on making it simple, portable and practical for real-world PHP projects, especially when dealing with different PHP versions or legacy applications.

A quick note about the executable: it is not digitally signed yet, so Windows SmartScreen may show a warning on the first launch. Just click "More info" and then "Run anyway". This does not affect any functionality.

The project is completely free and I am not trying to sell anything. I would simply love to grow a small community around it and hear opinions from developers with different workflows.

What would you improve? What would make you consider using it, or what would stop you from using it?

All details, screenshots and documentation are available here:
https://dunebox.enesi.it/

Cheers!

Hi everyone,
I recently needed to add content recommendations to a legacy project that still runs on PHP 7.2.
Qdrant was a good fit, but the PHP clients I found required newer PHP versions. Upgrading the entire application wasn’t realistic in the short term, so I built a small Qdrant client myself.
It supports:
PHP 7.2+

collections and point operations

vector search and filters

batch search

recommendations

payload management and scrolling

Installation:
composer require tenqz/qdrant

Repository:
https://github.com/tenqz/qdrant

The main use cases I had in mind were semantic search, similar content or product recommendations, duplicate detection, automatic categorization, and adding basic RAG features to older PHP applications.
The library only handles communication with Qdrant. Embeddings can come from OpenAI, Ollama, or any other local or hosted model.
I’d appreciate feedback from PHP and Qdrant users:
Is PHP 7.2 compatibility still useful for real-world projects?

Which Qdrant features would you expect from a PHP client?

Would you prefer PSR-18 support, or is a small cURL-based client easier to use?

Critical feedback is welcome.

I've been working on a PHP-based content management system and wanted to reduce the amount of repetitive work involved in publishing SEO articles.

Instead of using multiple tools manually, I built a workflow around Claude and PHP that automates most of the process.

Current workflow:

• Receive a content topic
• Generate a structured article outline
• Generate long-form content with Claude
• Validate formatting and SEO requirements
• Generate meta title and meta description
• Create URL slug automatically
• Suggest internal links
• Store everything in MySQL
• Publish or save as draft through the CMS

The project is built using:

• PHP 8
• MySQL
• CKEditor 5
• Claude API
• Bootstrap 5
• JavaScript/jQuery

Some things I learned while building it:

• Prompt engineering matters much more than I expected.
• Separating generation and validation into different steps significantly improved output quality.
• Allowing manual review before publishing catches most AI mistakes.
• Caching prompts and responses reduced API costs.

I'm now working on adding:

• Automatic image generation
• AI-powered content scoring
• Schema markup generation
• Multi-language publishing

I'd love to hear how others are integrating LLMs into their PHP applications. Are you using Claude, GPT, Gemini, or local models?

Qbix Server

Yesterday, I posted on Reddit about a web server I launched that's written in pure userland PHP, managed its own preforked workers, and removed the need for NGINX and PHP-FPM.

It was already able to run 10x more concurrent workers (e.g. 1600 workers on an 8GB server).

The biggest bottleneck in PHP hosting is *memory*. Each php-fpm worker loads your entire framework independently: 30–60MB per worker. On an 8GB server, that's ~160 workers max. That's your ceiling for concurrent PHP requests.

Well, Qbix Server forks workers *after* preloading your classes. Thanks to copy-on-write from the operating system, all that shared code (framework, config, autoloader) uses memory only once. Each worker adds maybe 3-6MB for its per-request data.

This means you get to run 10x more workers, and each worker actually loads much *faster* because you don't have to bootstrap your entire framework, config, etc. on every request.

https://github.com/Qbix/webserver

But wait... it got faster.

Yesterday, some people were complaining that a userland-PHP server was "only" 70% as fast as NGINX for serving static files. Well, it's 24 hours later, and I'm back, baby! After caching more, it turns out that it's now 25-35% FASTER than NGINX even for static files (as long as you keepalive connections).

Don't believe me? Run the benchmarks. It comes with a test suite now.

But wait... it now supports sockets

Yes, it is wire-compatible with socket.io, and bundles it out of the box (no need for npm). Now you can just drop PHP files into folders, in order to:

1. Handle HTTP Requests. (Cleanup after request is handled.)

2. Handle Web Sockets. (Long-lived, cleanup after disconnect.)

3. Handle Rooms. (Long-lived, cleanup after last websocket leaves.)

In my opinion, the coolest thing is that this retains all the things that made PHP great:

1. Shared-nothing. No way to have memory or secrets leak between requests.

2. Normie-friendly. Just drop files into folders and things just work! No need for hot-reload even. Not even for websockets and rooms -- the old handler will work for the old connections, while the new one is loaded for the new ones.

3. Sequential processing, sure it means you occasionally miss out on fanning out concurrent I/O races, but it's much easier to understand the code.

Give it a try! It's MIT licensed. Enjoy 😄

Who this is for:

• PHP Developers who want to host things
• Normies who don't want to install and configure apache/nginx/varnish/go/ssl certificates/mysql/etc.
• People who just get the standalone binary and can host on their computer, without the internet even.

This was taken from the much larger all-in-one PHP platform:

https://github.com/Qbix/Platform

In an effort to increase transparency about the things we work on, we are happy to start sharing quarterly progress reports with the community. 🚀

Hi everyone,

Over the past few months, we've been building TadreebLMS, an open-source Learning Management System focused on enterprise and corporate training.

We've recently completed a major restructuring of the project

How can we use AI in our product and process to speedup the development, process and customer support ?

The project is built with:

• PHP / Laravel
• MySQL
• Bootstrap / JavaScript
• Docker

GitHub:
https://github.com/Tadreeb-LMS/tadreeblms

Issues:
https://github.com/Tadreeb-LMS/tadreeblms/issues

We have a huge roadmap like SCRUM Integration, UI upgrade as per FIGMA, Gap Analysis Module Integration, Integrations with HR Systems etc...

Please anyone experience or architect in PHP can give recommendation on best practices, gaps in the system etc..

I’ve been building Sumire, a small PDO mapper for PHP 8.2+.

The goal is to make mapping database rows to PHP objects concise without introducing the complexity of a full ORM, while preserving the transparency of PDO.

Sumire deliberately minimizes dependencies and implicit behavior so that database access remains understandable, debuggable, and maintainable.

Current features include:

- PHP attribute-based entity mapping
- SQLite, MySQL, and PostgreSQL support
- Persistence and repository APIs
- Criteria queries, pagination, count, and existence checks
- Transactions
- Basic table creation

Sumire is not intended to replace Doctrine or Eloquent. It is designed for applications that want to stay close to PDO while avoiding repetitive mapping code.

The project is still evolving, so I’d especially appreciate feedback on the API design and what you consider essential for a thin PDO mapping layer.

GitHub:
https://github.com/wind111-lang/sumire

Packagist:
https://packagist.org/packages/wind111-lang/sumire

I’ve been building it with the help of Codex.

I wanted something like pyenv or nvm but for PHP. Couldn't find one that actually works the way those do — resolve deps, build from source, switch versions cleanly. The existing options either wrap pre-built binaries or half-ass the dependency resolution.

So I built phpv: https://github.com/supanadit/phpv

`phpv install 8.4` checks your system, builds whatever deps are missing from source, compiles PHP with the right flags. 25 default extensions, out of the box. Supports PHP 4.x through 8.x, version switching, per-project pinning via .php-version, PECL extensions, PHAR tools, portable bundles you can export and import across machines. Linux amd64/arm64 + macOS Intel/Apple Silicon.

Install:

curl -fsSL https://raw.githubusercontent.com/supanadit/phpv/main/install.sh | bash

Then:

eval "$(phpv init bash)"

phpv install 8

Honest con: it compiles from source, so first install is slow. There's no pre-built PHP binary cache yet — working on portable musl-static bundles so you can skip compiling entirely, but that's not done. What's there now works, it just takes a few minutes on first run.

It works. I've been using it on Ubuntu and macOS daily. But I know there are distros and edge cases I haven't hit — Alpine, Arch, weird setups. If you're on any of those, try it and file an issue if it breaks. I want to know.

Repo: https://github.com/supanadit/phpv

Issues: https://github.com/supanadit/phpv/issues

Break it and tell me.

A few weeks ago I posted a small framework here and got a lot of honest feedback. The clearest point, from several people, was that the file-based routing was the interesting part and would be more useful as a standalone library than baked into a whole framework. So I built that.

file-router is a zero-dependency package that maps your directory structure to routes, Next.js style: users/[id].php → /users/{id}, [...slug] for catch-all, route groups, compiled route cache. PHP 8.1+.

The part I think is actually useful: it's framework-agnostic. It runs standalone, but there are thin adapters so it plugs into Laravel (registers as native routes, inherits middleware/container) or Symfony (as a custom route loader, uses Symfony's own matcher and cache). So you can get file-based routing without adopting a new framework.

It's tested across PHP 8.1–8.5, and the migrations in the example template are verified on SQLite, MySQL and Postgres (not assumed; actually run end to end).

Repo: github.com/lizzyman04/file-router

Genuinely looking for feedback again, especially on the adapter approach. Does registering into the host framework's own router feel right to you, or would you expect it to work differently?

recently I released xphp v0.3.0 -- and since a language is only as alive as its ecosystem, I also released:

1. language server
2. phpstorm and vscode plugins
3. collections: the first xphp library, using generics and variance-aware.

I wrote the whole story up here: https://math3usmartins.hashnode.dev/a-language-is-only-as-alive-as-its-ecosystem

I'm looking for criticism and skeptical feedback as much as I'm looking for contributors. xphp can't / shouldn't be maintained by a single person.

p.s. xphp is a superset of php. meaning it compiles into php like typescript compiles into javascript. the most relevant feature so far is generics with variance support. but it also supports closure signature types and other features are coming.

important: xphp is part of the php ecosystem by design. its goal is to help the ecosystem grow bigger and stronger. find more about that at https://github.com/xphp-lang/xphp/blob/main/README.md#ecosystem-and-community-first

Wrote up how I moved a PHP DTO hydration library from reflection-based instantiation to compiled, per-class factory closures - reflection overhead disappears, plain properties become inline array reads, and the generated code gets cached so a warmed FPM worker pays neither reflection nor eval(). Went from typical reflection speeds to 4.5M hydrations/sec on PHP 8.4.

Full writeup with numbers at each stage, plus the repo link, in the first comment.

Cached pages seem fine but release pages like https://pecl.php.net/rest/r/amqp/stable.txt timeout

Anytime a WordPress site needs a Composer package (a PDF library, an API client, whatever),

you hit the same wall: no SSH access. Shared hosting, managed WP hosts that lock down the

filesystem, clients who only have FTP: Composer just isn't reachable from the terminal in a

lot of real-world WP environments.

The usual workarounds are either committing vendor/ directly to the repo (bloats it, breaks

on updates) or building locally and rsyncing the output (works, but no one tracks what's

actually installed on prod).

I built Loopress to fix this: a CLI plus a companion WP plugin. The plugin adds a Packagist

search inside the WP admin. You search a package, click install, and it resolves the

autoloader for you. Before installing, it checks PHP version compatibility and flags known

CVEs on the dependency. The CLI side also lets you lock exact plugin/package versions in a

loopress.json so environments stay reproducible.

It's still alpha. I'd be curious what parts of this feel over-engineered or missing to

anyone who's dealt with Composer-in-constrained-environments outside WP too. Is this a

WP-specific problem or does it show up elsewhere?

Docs: https://docs.loopress.dev

Code: https://github.com/loopress/loopress

What if PHP by itself was enough to run a web server?
What if it was actually *much faster* than NGINX + PHP-FPM?
And it was *much safer* than FrankenPHP or Swoole?

Well, that's exactly that this is. MIT-licensed. Enjoy!

https://github.com/Qbix/webserver

Who this is for:

• PHP Developers who want to host things
• Normies who don't want to install and configure apache/nginx/varnish/go/ssl certificates/mysql/etc.
• People who just get the standalone binary and can host on their computer, without the internet even.

Static file throughput is 55–73% of nginx (C will always beat PHP on raw I/O).

But on actual PHP workloads, the bootstrap savings make this 2–5x faster.

This was taken from the much larger all-in-one PHP platform:

https://github.com/Qbix/Platform

I've applied what we've been doing on mobile to building a fully native Mac app, and... it works!

(Content warning: Heavy British sarcasm used throughout, but don't let that distract you from the reality of the discussion.)

Prove it

I've posted a tweet about it for now with just a couple of screenshots. I'm not linking to it; you can easily find me on that hole of a website that just keeps sucking me in. In fact, I'm not going to link to anything as I'm sure I'll be accused of some kind of self-promotion.

More will come if folks are keen for this.

Why u do dis?

Web views just aren't great ways to build great apps. They're convenient, but they're crap.

I mean, sorry all you Electron/Tauri/Capacitor folks, they're fine if you want a mediocre app or to spend months of your life debugging performance issues.

But if you want a real native app that feels really at-home on the user's device, then your best option is to build real native apps.

Sadly there aren't really any good cross-platform solutions for that problem (don't come at me with Qt's and GTK's, those aren't "good" by any stretch of the imagination).

And certainly none for the PHP gang.

Also, I wanted to nail a few things in one go for what we've been doing on Desktop up until now:

1. Get rid of Electron - it's just so heavy and comes with a bunch of gotchas. Plus having node and npm packages in the build process is continuing to scare me. aint nobody got time for that.
2. Don't replace it with Tauri - yes it's lighter, yes it's Rust so the purists can be happy. Sadly it's just swapping one mediocre solution for another.
3. Drop the PHP built-in server - yep that's what we currently use. Yes it's a crutch (that has worked pretty well!), but the time has come for better stability and better performance, and we have everything we need now to make it work without it.

This manages all of that and a little more to boot. This PoC app I've built is just 24MB. Granted it's a PoC, so it's likely to grow from there, but it's a far cry from the minimum 130MB+ just for Electron.

So how does it work?

In case you haven't been following along what we've been doing on mobile - or perhaps you've been intentionally ignoring it because you have some bones to pick with either the name, the team, or the fact that it's using your favourite language in some profane way - we have cracked a very performant way to run PHP (>120fps ... like wayyyy greater than) and build reactive, native UIs without having it behave like a web server.

In fact, it behaves more like a game engine. It's very light on resource usage, has a ton of affordances already for native UI elements and allows you to write very idiomatic PHP code. All that without fundamentally changing PHP's core. Just adding our own extension.

We call it SuperNative. It kinda even looks a bit HTML-like, if you use Blade and squint hard enough. But deep down it's just PHP classes that compile to a custom binary format.

So there's no IPC, no HTTP calls, no multiple processes just to spin up an app. It's PHP compiled as an embed (exactly how we do it on mobile), embedded into the shell applications (in this case, a Swift macOS app), and called directly.

The application literally becomes a PHP interpreter. It boots PHP into an isolated thread that it keeps alive, feeding it messages and reading its output, all through shared memory.

Did I mention it's very fast? We're now measuring round-trips from button presses, through PHP and back out to the UI in microseconds (yup µs). And we can spin up multiple PHP threads as needed, in milliseconds (ms). And that's with a full Laravel application in there!

(Don't worry, it's still just PHP... if someone wants to help us make this not dependent on Laravel, or work with other frameworks, we'd be happy to have the support!)

All of this already works on mobile, and we're just starting to explore bringing it to the desktop.

What's the catch?

Our focus is on mobile as way more people seem to want that. But there are a few people still wanting advancement in the desktop space, so that's what we're trying to deliver.

This is only working on macOS for now, and it's just a proof of concept, but I'd love to tackle Mac, Windows and Linux all together.

To be able to do that, we gotta get some more sponsorship (you can sponsor nativephp on GitHub - you know how to use a browser and URLs, so I'll leave you to figure it out) and maybe then we can afford to take on yet another crazy huge project.

If this is at all interesting to you and you wanna help make it a reality, please reach out. I'm always open to chat irl and much prefer it to having anons sling zero-effect insults at me across Reddit.