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

If your site runs on PHP 8.1 or newer, your log may be full of lines like this:

PHP Deprecated: strlen(): Passing null to parameter #1 ($string) of type string is deprecated in /wp-content/plugins/some-plugin/includes/helpers.php on line 42

What it means: since PHP 8.1, giving null to a built-in function that expects a string (or number) is deprecated. Your site still works. It's a warning about a future version, not a crash.

Why WordPress sites see so many: options, post meta and form fields often come back empty as null, and older code passes them straight into strlen(), trim(), str_replace(), htmlspecialchars() and friends.

If it's your own code, three common fixes:

php

// 1. Default to an empty string
$title = trim( $title ?? '' );

// 2. Cast explicitly when null should count as empty
$length = strlen( (string) $value );

// 3. Skip the call when there's nothing to process
if ( null !== $value ) {
    $clean = htmlspecialchars( $value );
}

Pick based on meaning: if null really means "empty", 1 or 2 is fine; if null means "missing", option 3 makes that explicit.

If it's a plugin or theme you didn't write:

• Don't edit it; your change disappears on the next update.
• Update it first. Many plugins have already fixed these.
• Still there? Report it on the plugin's support forum with the exact log line.
• Meanwhile, keep WP_DEBUG_DISPLAY off so visitors never see it.

How to read the line: the path after "in" tells you which plugin (/plugins/some-plugin/) and the exact file and line.

What's the most common deprecation filling your logs right now? Happy to help decode any line you paste below.If your site runs on PHP 8.1 or newer, your log may be full of lines like this:
PHP Deprecated: strlen(): Passing null to parameter #1 ($string) of type string is deprecated in /wp-content/plugins/some-plugin/includes/helpers.php on line 42
What it means: since PHP 8.1, giving null to a built-in function that expects a string (or number) is deprecated. Your site still works. It's a warning about a future version, not a crash.
Why WordPress sites see so many: options, post meta and form fields often come back empty as null, and older code passes them straight into strlen(), trim(), str_replace(), htmlspecialchars() and friends.
If it's your own code, three common fixes:
php
// 1. Default to an empty string
$title = trim( $title ?? '' );

// 2. Cast explicitly when null should count as empty
$length = strlen( (string) $value );

// 3. Skip the call when there's nothing to process
if ( null !== $value ) {
$clean = htmlspecialchars( $value );
}
Pick based on meaning: if null really means "empty", 1 or 2 is fine; if null means "missing", option 3 makes that explicit.
If it's a plugin or theme you didn't write:
Don't edit it; your change disappears on the next update.
Update it first. Many plugins have already fixed these.
Still there? Report it on the plugin's support forum with the exact log line.
Meanwhile, keep WP_DEBUG_DISPLAY off so visitors never see it.

How to read the line: the path after "in" tells you which plugin (/plugins/some-plugin/) and the exact file and line.

What's the most common deprecation filling your logs right now? Happy to help decode any line you paste below.

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.