PHPStan 2.2.6 adds a native PHP extension (PHP 8.3+) written in C++ that makes running PHPStan 10-30 % faster.

PHPStan's Composer package ships prebuilt binaries for the most common platforms — Linux (glibc and musl, x86_64 and arm64), macOS, and Windows (x86_64), for PHP 8.3 and newer — and PHPStan automatically loads the one matching your runtime into its worker processes. You don't have to do any extra work to take advantage of this!

If you run PHPStan through manually downloaded phpstan.phar, you can run it with extension by installing it with PIE:

pie install phpstan/turbo

The extension only activates when its version matches the one your PHPStan release expects — on a mismatch PHPStan prints a note and runs without it, so an outdated extension can never affect results, only speed.

Only a handful of hot paths are currently rewritten in the extension. There's room for the performance gain to grow if we ever decide to rewrite more parts natively.

The extension is completely optional, PHPStan still works without it. When the extension gets enabled, its implementation shadows certain PHPStan classes designed for this. They are marked with the #[ShadowedByTurboExtension] attribute.

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

[!WARNING] This language server may not be the one you're looking for.

I personally use it and will continue to maintain it until I don't use it anymore. There are new and interesting open source language servers being developed that can offer far more performant capabilities. I think Phpactor still offers some great features, especially in regards to code actions and I genuinely miss some functionality when using servers for Rust, Go and Typescrript.

There are many parts of this project that I'm proud of but ultimately it has some major short-comings in regards to perforamnce, accuracy and scalability that I'm not capable of addressing at this time. YMMV.

Not op. Just reposting

In recent months, I have noticed that more and more people are making attempts to create PHP AOT compilers. In particular, recent ones are Elephc (https://elephc.dev/) and TypePHP from the Swoole team (mentioned here several times). Years earlier, I recall attempts such as jPHP and Peachpie, and the most inspiring to me was https://github.com/ircmaxell/php-compiler. Probably there were a lot more.

However, almost all of them rely on other programming languages (e.g., Rust, C++). So, one day I asked myself, 'What actually prevents someone from writing the PHP compiler in PHP?'

At this point, I've decided I should try even though no one asked. My experience with real compilers is pretty limited, and I didn't have much time to learn everything from scratch, but in the present times, we have great LLM tools that allows to make some stuff faster.

Then I spent a few weekends making this concept - took the LLVM backend and tried to make a PHP frontend around it. To be honest the most of the "compiler" is AI-coded/slopped and requires heavy refactorings, but I do not pretend to say it is production-ready. It is no more than a working concept with some limited PHP-subset supported.

Not op. Just reposting

I published this guide today, which explains some of the best practices for building production-ready Docker images for your PHP applications which use Composer to install dependencies.

This includes using Composer without leaving the binary in your production image, running the composer install command with the correct flags, excluding your local vendor directory from the build context, optimizing cache to speed up consecutive builds, optimizing the Composer autoloader, and passing authentication credentials to Composer to install packages from private registries.

https://nth-root.nl/en/guides/composer-in-docker-best-practices-for-production-images

You can now join the PHP Ambassador Special Interest Group if you want to help improve the perception of PHP in spaces outside our bubble. Help us help the community tell the real story of modern PHP development! hashtag#php hashtag#phpc

cross-posted from: https://lemmy.world/post/48266338

I am learning how to use Symfony Mailer and am a bit lost on the encrypting message section.

This is my simple code below which works in sending the email.

<?php

require 'vendor/autoload.php';

const FROM = 'me@example.com';

const TO = 'example@email.com';

const SUBJECT = 'My Subject';

const MESSAGE = 'Hello World';

const DSN = 'smtp://localhost:1025';

$transport = \Symfony\Component\Mailer\Transport::fromDsn(DSN);

$mailer = new \Symfony\Component\Mailer\Mailer($transport);

$email = (new \Symfony\Component\Mime\Email())
    ->from(FROM)
    ->to(TO)
    ->subject(SUBJECT)
    ->text(MESSAGE);

$encrypter = new \Symfony\Component\Mime\Crypto\SMimeEncrypter('my-certificate.crt');
$encryptedEmail = $encrypter->encrypt($email);

try {
    $mailer->send($encryptedEmail);
} catch (\Symfony\Component\Mailer\Exception\TransportExceptionInterface $error) {
    echo 'Unable to send email' . PHP_EOL;
}

And this is how I generated the certificate and key...

openssl genrsa -aes256 -out my-certificate.key 4096
openssl req -new -x509 -days 29220 -key my-certificate.key -out my-certificate.crt

I am able to receive the email using SMTP tools like Mailpit.

My two questions are...

1. My emails are encrypted using the certificate, but shouldn't it be done using PGP?
2. How do I decrypt the email with SMTP testing tool or any online or CLI tool? I tried to decrypt the email and could not decrypt it even though I have all of the keys.

cross-posted from: https://programming.dev/post/42626008

Not yet released.

PHP, a server-side programming language used mainly for building dynamic websites and web applications, has just released version 8.5, a major update that adds new syntax, expanded attribute support, performance improvements, and multiple RFC-driven features.

One of the most significant additions is the new built-in URI extension. It provides a consistent API for parsing and modifying URLs, following both RFC 3986 and the WHATWG URL standards. Backed by uriparser and Lexbor, it replaces parse_url() in scenarios where accurate, standards-compliant handling is required