标签：#HP

The moment you add a code quality gate to CI, something quietly changes on your team. Developers stop arguing about code style in reviews because the robot handles it. Static-analysis errors stop reaching production because they can't pass the gate. You stop inheriting other people's technical debt because new errors are blocked immediately, even if old ones exist. That last point is the PHPStan baseline trick. We'll get to it. The Code Quality Job This job runs on every push and is intentionally fast — no database, no migrations, just PHP and a vendor folder: quality: name: Code Quality runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Setup PHP 8.4 uses: shivammathur/setup-php@v2 with: php-version: '8.4' extensions: mbstring, pdo, bcmath, zip, intl coverage: none tools: composer:v2 - name: Cache Composer dependencies uses: actions/cache@v4 with: path: api/vendor key: php-8.4-composer-${{ hashFiles('api/composer.lock') }} restore-keys: php-8.4-composer- - name: Install dependencies run: composer install --no-interaction --prefer-dist --no-progress - name: Check formatting (Laravel Pint) run: ./vendor/bin/pint --test - name: Static analysis (PHPStan) run: ./vendor/bin/phpstan analyse --memory-limit=2G --no-progress pint --test runs in read-only mode — it checks without modifying files. Exit code 1 if any file has style drift. Run ./vendor/bin/pint locally (without --test ) to auto-fix before pushing. Configuring PHPStan Add a phpstan.neon to your API root: parameters: level: 8 paths: - app - Modules excludePaths: - vendor ignoreErrors: - identifier: missingType.iterableValue - identifier: missingType.generics Level 8 is strict. On a fresh project, aim for it from day one. On an existing codebase, start at level 4 and raise it gradually. The Memory Problem PHPStan at level 8 on a large codebase needs more than 512MB of RAM. Use --memory-limit=2G in CI. Locally, add a shortcut to composer.json : "scripts": { "analyse": "php -d memory_limit=2G vendor/bi

Five failure patterns from past WordPress major upgrades ended with the observation that "the same structures will recur in some form in the next major (7.0 or 8.0)." This post applies that pattern knowledge to WordPress 7.0 specifically — not as a list of things that will happen, but as a preparatory checklist for what you can verify now. This sits alongside the seven-item pre-flight checklist from W1 rather than replacing it. Think of it as the 7.0-specific supplement. Item 1 — PHP minimum requirement increase (W3 pattern 3 again) W3’s pattern 3 was "older plugins break with parse errors when the PHP minimum requirement is raised." This pattern repeats on every major upgrade cycle. WordPress 7.0 is expected to follow the same trajectory. Background: PHP 7.4 reached end-of-life from the PHP project in November 2022 (security support ended November 2023) WordPress 6.6 requires PHP 7.2 minimum WordPress 7.0 is expected to raise the minimum to PHP 8.0 or later When this happens, sites running PHP 7.x will encounter plugins and themes that "worked fine before" but break with syntax or fatal errors after the upgrade. The mechanism is the same as past cycles — the plugin hasn’t updated its code to handle PHP 8.x stricter type handling, and the errors surface only at runtime. What you can check now: # Confirm the server’s PHP version php -v # List all plugins with their current version and update status wp plugin list --fields = name,version,update,update_version --format = table # Run a JSON output check — noisy output here means PHP warnings already leaking wp plugin list --format = json The pattern to watch for: plugins with an old "Tested up to" value and no updates in the past year. These are the highest risk candidates for PHP compatibility issues when the minimum requirement moves. The post on PHP 8.2 Deprecated warnings leaking into WP-CLI JSON output covers a related symptom — even when PHP compatibility doesn’t cause a hard break, it can silently corrupt o

I love InertiaJS to the point where it's becoming a personality trait I tend to want to use it for everything, but adding Inertia to an existing Laravel API gets awkward fast. Same thing happens in the other direction: you start with a full Inertia frontend and then realize you want to expose some of that data as a public API too. The naive solutions are: Sprinkle if ($request->wantsJson()) into your controllers Maintain two separate routes that return the exact same data Neither feels right. So I made inertia-split Starting fresh with Inertia: serve both from the same controller class ProjectController extends Controller { use HasHybridResponses ; public function index () { return $this -> respond () -> component ( 'Projects/Index' , [ 'projects' => Project :: all (), ]); // Inertia request → renders the Svelte/Vue/React component // API request → returns JSON } } The controller doesn't check anything. Inertia requests get an Inertia response, API clients get JSON. Existing API? Don't touch it If you just want to make an existing API method Inertia-aware, one annotation is enough: #[InertiaComponent('Users/Show')] public function show ( User $user ): array { return [ 'user' => $user ]; } The method body stays exactly as it was. Inertia requests get the component rendered with your data as props. Everything else gets the same JSON as before. Methods without the annotation are completely unaffected. Wait, how does this even work? The package can out Inertia's ResponseFactory for its own in the service provider (opt-in): $this -> app -> singleton ( ResponseFactory :: class , HybridResponseFactory :: class ); // checks if it's an Inertia request and returns appropriate response Good old OOP. Thank you polymorphism. Wrap-up Whatever the direction of your problem, making Inertia and API endpoints use the same controller is a big win. You're still responsible for writing routes and wiring middlewares, but this should save a lot of time and effort. Still in beta, use accor

Technical books have a shelf life that nobody prints on the cover. A cookbook from 2018 still works. A history book from 2018 still works. A Laravel book from 2018 will teach you a middleware pattern that was replaced twice, recommend a package whose maintainer archived it, and show you a test suite in a syntax that no longer runs. I've written a series of ebooks on PHP, OOP, SOLID, design patterns, Laravel conventions, testing with Pest, application architecture, and AI-assisted development. There are also two aimed at kids learning to code. Every one of them was correct when I wrote it. That is a much weaker claim than "correct now," and I'd rather find the gap myself than have a reader find it for me. So: I'm opening the series to technical reviewers before the final edition ships. Applications close Sunday, 26 July. Why I can't do this alone Not because I lack the time. Because I lack the distance. When you write a technical book, you build a mental model of the reader and then you write to that model for months. The model is always partly wrong, and you are the last person who can see how. You skip a step because it's obvious to you. You keep an example that made sense when you drafted the chapter and no longer matches the surrounding code. You cite a package because it was the right answer for a project you shipped two years ago, and you never checked whether it's still maintained. None of this shows up on a reread. Rereading your own work is mostly pattern-matching against your own memory. You see what you meant, not what you wrote. A reviewer who has never seen the manuscript reads what's actually on the page. That's the whole value, and it's not something more effort on my side can substitute for. What the job actually is You pick one book from the series. You read it properly — not skim it — and you flag what's broken. Four things in particular: Things that are outdated. The framework moved, the syntax changed, there's now a cleaner way to do the same thin

Are you tired of wrestling with raw cURL requests, parsing Server-Sent Events (SSE) by hand, and building complex polling loops just to interact with trading APIs? If you are a PHP developer or a Laravel enthusiast looking to dive into algorithmic trading, your life is about to get a whole lot easier. Meet coinquant-php , the official PHP and Laravel SDK for the CoinQuant Public API. CoinQuant is revolutionizing the way we approach algorithmic trading. It takes a trading idea described in plain English and turns it into a backtestable strategy using advanced AI. However, integrating such powerful tools into your own applications can often be a daunting task. That is where coinquant-php steps in. This robust SDK wraps the public API, providing a seamless, developer-friendly experience that lets you focus on what really matters: building profitable trading strategies. In this comprehensive guide, we will explore why coinquant-php is a game-changer for PHP developers, delve into its standout features, and show you how to get started in minutes. Why Choose CoinQuant PHP? The landscape of algorithmic trading is often dominated by Python, but PHP remains a powerhouse for web development, especially with frameworks like Laravel. coinquant-php bridges the gap, allowing PHP developers to leverage the cutting-edge AI capabilities of CoinQuant without leaving their preferred ecosystem. 1. Built for Modern PHP The library is designed for the modern era of PHP. It requires PHP 8.1+ and embraces strict typing, ensuring your code is robust and free from legacy baggage. Whether you are building a standalone script or a complex enterprise application, the SDK provides a solid foundation. 2. First-Class Laravel Integration If you are using Laravel 10, 11, 12, or 13, you are in for a treat. The package auto-registers its ServiceProvider and Facade , meaning there is absolutely zero manual wiring required. You can simply install the package and start using the CoinQuant facade anywhere

When a learner finishes a course they want a certificate that behaves like a document: something they can print at full quality, attach to a job application and that an employer can check is genuine. In this tutorial you'll build exactly that in Laravel: a Blade-designed certificate rendered as a vector PDF, with a QR code that resolves to a verification page and an email that delivers it automatically. This post originally appeared on Accreditly as How to generate verifiable PDF certificates in Laravel . Keep the design in Blade The certificate is an ordinary Blade view. Everything lives in one file, styles inline, so the markup you preview in the browser is exactly what gets rendered. If you want a designed starting point rather than a blank page, the certificate of completion template is a good base to adapt. {{-- resources/views/certificates/template.blade.php --}} <!doctype html> <html> <head> <meta charset="utf-8"> <style> body { font-family: Georgia, serif; color: #1a2233; margin: 0; } .certificate { padding: 60px; border: 6px double #b28a2f; margin: 24px; text-align: center; } .heading { font-size: 15px; letter-spacing: 4px; text-transform: uppercase; color: #b28a2f; } h1 { font-size: 44px; margin: 24px 0 8px; } .course { font-size: 22px; margin: 4px 0 28px; } .issued { font-size: 15px; color: #5a6478; } .qr { margin-top: 36px; } .verify-url { font-size: 12px; color: #5a6478; } </style> </head> <body> <div class="certificate"> <p class="heading">Certificate of Completion</p> <h1>{{ $certificate->user->name }}</h1> <p class="course">has completed {{ $certificate->course }}</p> <p class="issued">Issued {{ $certificate->issued_at->format('j F Y') }}</p> <div class="qr"> {!! QrCode::size(110)->generate(route('certificates.verify', $certificate)) !!} </div> <p class="verify-url">{{ route('certificates.verify', $certificate) }}</p> </div> </body> </html> Two things are doing quiet work here. The design flows like a document rather than being pinned to fixed pixel

It is time to bring opposites together, to stir up these stagnant waters, and to restore an industry that is dynamic from within, with multiple connections that were previously impossible or unimaginable. In the previous parts of this series, we explored how PureScript acts as a quiet rewrite of the Web , offering a territory of mathematical precision above JavaScript, and how its universal polymorphism allows it to target wildly different runtimes like Node.js, Erlang's BEAM, Chez Scheme, etc. But hey, what about the elephant in the room? Yes, what is running the majority of the web, today, in the shadow? You know. The eternal one, the big one, the one whose death everyone talks about, but who never truly dies. PHP. While the modern JavaScript ecosystem (among others) races toward edge computing and containerized microservices, around 70% of the web is still powered by PHP . From legacy WordPress sites to affordable shared hosting (cPanel, OVH, GoDaddy, basic LAMP stacks), a massive portion of the internet lives in environments where escaping the PHP runtime is either financially unviable, technically impossible, or simply unnecessary. And yet... For a long time, the PHP ecosystem has been left without a true, strictly typed functional and safe alternative, like TypeScript for Javascript. Even though recent PHP versions introduced fantastic features (short closures, match expressions, Fibers), the frustration that comes with its historical limitations and dynamic typing remains very real for some of its users. Very well! This is why I built phpurs : a brand new compiler backend that transpiles PureScript directly to modern PHP 8.4+ syntax. It is no longer a proof of concept. It is passing the official PureScript test suite , and it is ready for production. Here is how we bring the elegance of purely functional programming to the big web, while keeping deployment as simple as a legacy FTP upload, or anything alike. The easy deployment paradox In modern DevOps, deplo

When a new video shows up in one of our regional crawlers, three things need to happen almost immediately: the SQLite FTS5 search index for that region needs a new row, the discovery ranking cache needs to be invalidated, and the sitemap generator needs to know a URL was born. For a long time we did all of this inline, inside the same cron process that fetched the video. It worked until it didn't. A slow FTS5 rebuild would stall the fetch loop, a sitemap write would fail silently, and a crash halfway through meant one region had the video indexed and another didn't. The fetch and the fan-out were fused together, and every failure was a partial failure. The fix was to stop treating "a video was discovered" as a function call and start treating it as an event. At TrendVidStream we run discovery across 8 regions, and the moment we introduced NATS JetStream as the spine between the crawler and the downstream consumers, the whole system got calmer. This post is the concrete version of how we did it: the stream config, the publishers, the consumers, and the mistakes we made that you can skip. Why Not Just Use a Queue Table in SQLite We already had SQLite everywhere, so the obvious move was a jobs table. We tried it. The problems showed up fast: Polling latency vs. load tradeoff. Poll every second and you hammer the DB with mostly-empty SELECT queries across 8 regions. Poll every 30 seconds and your search index lags noticeably behind your crawler. No fan-out. One row, one worker. If the sitemap generator and the FTS5 indexer both need the same event, you either duplicate rows or invent a consumed_by bitmask. Both are ugly. Locking. SQLite's writer lock means the queue table and the actual data table start contending under the multi-region cron bursts we run. Cross-region delivery. Our regions aren't all on the same box. A queue table doesn't cross machines without you building a replication story on top. JetStream solves all four: push-based delivery (no polling), multipl

When I started working on a WooCommerce slider plugin, I noticed that many existing solutions were packed with features that a lot of websites simply don’t need. More features often mean more CSS, more JavaScript, and a bigger impact on performance. So I asked myself a simple question: What would a WooCommerce slider look like if performance came first? My goals Instead of creating another all-in-one slider plugin, I focused on a few principles: Lightweight codebase Fast loading times Responsive by default Easy integration with Gutenberg Elementor support Shortcode support Clean and maintainable architecture Performance matters Every additional request and every unnecessary asset affects page speed. Some optimizations I implemented include: Assets are loaded only when required. Local libraries instead of unnecessary external requests. Server-side rendering where appropriate. Clean HTML output. Developer experience I also wanted the plugin to be simple for users. Instead of a complicated interface, the goal was: Install Create a slider Insert it into a page Done Lessons learned Building a public WordPress plugin taught me a lot: Documentation is almost as important as the code. User feedback quickly reveals edge cases you never considered. Keeping the codebase simple often leads to better long-term maintainability. What’s next? I’m continuing to improve the plugin by adding new features while keeping performance as the top priority. I’d also love to hear how other developers approach WordPress plugin development and performance optimization. Thanks for reading! ⸻ If you’re interested, you can check out my project here: WordPress.org: https://wordpress.org/plugins/amitry-product-category-slider/ GitHub: https://github.com/amitry-de/amitry-product-category-slider Live Demo: https://slider.amitry.de/

stoneChat is a locally hosted LLM web chat client built specifically for Windows XP-era machines and Internet Explorer 6. The frontend remains compatible with IE6. A small PHP server handles the chat requests, while stunnel provides HTTPS support for modern API endpoints. Models are defined in an INI file. Each model can have its own API endpoint, API key, model ID, streaming setting, token limit, and timeout. OpenAI-compatible APIs are supported. The same configuration file also manages users, model access, language preferences, and keyboard behavior. stoneChat runs on Windows with PHP 5.4 or newer and starts through RUN.cmd. GitHub: https://github.com/Water-Run/stoneChat License: WTFPL

Resellers threatened to ditch HP printing supplies for counterfeits.

Repo: https://github.com/voku/agent-loop Demo: https://voku.github.io/agent_loop_demo/ Your Coding Agent Doesn’t Need More Memory. It Needs a Governed Loop. Coding agents repeat mistakes. The obvious response is to give them more memory: MEMORY.md project-rules.md agent-notes.md lessons-learned.md MEMORY_FINAL.md Soon the agent receives old decisions, temporary workarounds, copied transcripts, abandoned ideas, and rules nobody remembers approving. It has more context. It does not necessarily have better context. At some point, memory becomes landfill. The problem is not that coding agents forget too much. The problem is that most workflows fail to distinguish between temporary context, evidence, proposed learning, and approved project guidance. A transcript is not memory. A note is not a rule. A finding is not guidance. And a successful patch is not automatically a project convention. Instead of giving the agent one growing pile of context, I built voku/agent-loop around a governed workflow: task -> approved plan -> selective recall -> implementation -> verification -> recorded evidence -> reviewed learning Start with approved scope A coding agent should not begin by reading a ticket and creatively filling in everything the ticket forgot to mention. It should begin with an explicit work brief: goal; permitted scope; non-goals; affected files; required validation; human approval. For example: vendor/bin/agent-loop workflow plan PROJECT-123 \ --by lars \ --learning-root infra/doc/agent-learning \ --file src/Order/OrderService.php \ --file tests/Order/OrderServiceTest.php \ --goal "Reject invalid order state transitions" \ --scope "Order state validation and its tests" \ --non-goal "Do not redesign the order aggregate" \ --validate "composer phpstan" \ --validate "composer test" A human then approves that specific revision: vendor/bin/agent-loop workflow approve PROJECT-123 --by lars When the plan changes, the old revision becomes superseded , and the new one requires

The companion to the seven things to check before a WordPress major upgrade is the question that comes right after: when do you actually apply it? A new WordPress major drops today. Do you ship it to production tonight? Tomorrow? In a week? Hold for the next scheduled monthly maintenance? This call tends to live in tribal knowledge, but a few clear axes combined together give you a calibration framework you can apply every time without re-deciding from scratch. Here are five axes worth using. Premise — majors are not security patches The first thing to anchor: a major upgrade is not a security patch . WordPress ships security fixes via minor releases ( 6.4.1 → 6.4.2 , 6.5.0 → 6.5.1 — the second-digit bumps ). Those are same-day apply by default . Major releases ( 6.4 → 6.5 , eventually some 6.x → 7.0 ) carry new features and API changes; they aren't released to be applied immediately for security reasons. Without this distinction, the felt urgency of " we have to apply this for security " pushes you to rush majors that should wait. Minors immediately, majors by judgment — that separation is the first rule worth writing down. Axis 1 — wait for x.0.1 For essentially every major release, x.0.1 (the first patch release) lands within 1–3 weeks and absorbs the critical bugs that surfaced after launch. Past examples have included things like "the admin goes white under specific settings," "a particular theme breaks the block editor," "DB migration stalls in specific environments." Nobody hit these on launch day; they emerged as the world started using it for days or weeks. Just waiting for x.0.1 instead of x.0 sidesteps most of those launch-window bugs. For the first few weeks after a major lands, the world's WordPress installations are effectively running the beta test . Being downstream of the people who hit the mines is the rational position for a maintenance practice. Axis 2 — wait until major plugin vendors update "Tested up to" The thing that breaks most after a majo

WordPress major version upgrades (5.x → 6.x, and eventually 6.x → 7.x) are a different animal from minor releases. Minor releases (like 6.4.1 → 6.4.2) are mostly bug fixes with low compatibility risk. Majors land API deprecations, raised PHP minimum requirements, and core block replacements all at once — and those things hit operations hard. The " just hit Update in the admin and patch whatever breaks " workflow can survive on a single personal site, but it tends to fall apart under multi-site maintenance — simultaneous failures across sites overwhelm root-cause triage. This post collects the things worth verifying before you run a major upgrade, as a seven-item checklist . 1. Has the minimum PHP version been raised? Major WordPress releases sometimes raise the minimum supported PHP version (6.6 lifted it to PHP 7.2.24, and a future 7.0 will very likely require PHP 8.x). What matters operationally isn't just the server's PHP version and WordPress's stated minimum — it's the intersection with the PHP versions your plugins and themes actually run on . You can usually upgrade your server's PHP, but older themes and plugins not running on new PHP isn't rare. A subtle failure mode here: traps like PHP 8.2+ deprecated warnings leaking into older WP-CLI JSON output , where nothing visibly errors but your operational tooling silently breaks. Before upgrading, run wp plugin list --format=json on the production PHP environment and verify you're getting clean JSON. That one check catches a lot of post-upgrade pain. 2. Audit "Tested up to" for every plugin Each plugin's readme.txt carries a Tested up to: X.X line — the developer's declaration of the highest WordPress version they've actually tested against . It's the first signal for major-upgrade compatibility audits. WP-CLI gives you the inventory in one shot: wp plugin list --fields = name,version,update_version,update --format = table Plugins where "Tested up to" is old AND no updates in the last year deserve scrutiny. Acti

The problem I've been working with Manticore Search for about two years at EricaPRO , building the search layer for two financial data platforms. For the past year, that work has been a Laravel API. Manticore was never the problem. It's fast and it's stable. The problem was the gap between Manticore and Laravel. I had already built a package for this — laravel-manticore-search , a fluent builder over Manticore's HTTP/JSON API. It works, and it's still in use. But it's a client wrapper. Every feature had to be implemented manually. Every new filter or facet meant more custom architecture around the client, and none of the things Laravel gives you for free — models, migrations, pagination, casts — applied to it. Scout doesn't close that gap either. Scout gives you search() . No full query builder, no migrations for your indexes, sync is your problem. That's not a criticism — Scout abstracts over engines with completely different APIs, so it exposes the lowest common denominator. It just wasn't what I needed. What I needed was simple to describe and annoying to not have: something plug and play. Something Laravel way. Point Eloquent at Manticore and use Eloquent. The insight Manticore speaks the MySQL wire protocol. Out of the box, port 9306. You can connect to it with any MySQL client and run SQL. I had been using that port for two years without thinking about what it meant for Laravel. Because here's the thing: all of Eloquent — models, query builder, migrations, pagination, chunking — sits on top of a Connection and a Grammar . The grammar compiles builder calls into SQL for a specific dialect. That's the entire mechanism behind Laravel supporting MySQL, Postgres, SQLite and SQL Server with one codebase. So the real question was never "how do I re-implement Eloquent on top of Manticore's client?" It was "how thin can a Manticore grammar be?" If Manticore accepts MySQL-protocol connections and mostly-MySQL SQL, then a Laravel database driver — a custom connection plu

Getting the public IP in PHP — no dependencies, no API key PHP is still one of the most widely deployed server-side languages, running a significant share of the web's backend code. If you're building a PHP application that needs the public IP address — for geolocation, DDNS, diagnostics, or country detection — this article covers the common patterns using IPPubblico.org : free, no key, HTTPS, JSON and plain text endpoints. Use case 1 — Your server's own public IP (one-liner) The simplest case: a PHP script that needs to know its own public IP. <?php $ip = trim ( file_get_contents ( 'https://ipv4.ippubblico.org/' )); echo $ip ; // 203.0.113.42 file_get_contents works if allow_url_fopen is enabled (it is by default on most servers). If not, use cURL (see below). Use case 2 — With cURL (recommended for production) file_get_contents has no timeout control and minimal error handling. For production code, cURL is better: <?php function getPublicIP (): ?string { $ch = curl_init ( 'https://ipv4.ippubblico.org/' ); curl_setopt_array ( $ch , [ CURLOPT_RETURNTRANSFER => true , CURLOPT_TIMEOUT => 5 , CURLOPT_FOLLOWLOCATION => true , CURLOPT_SSL_VERIFYPEER => true , ]); $response = curl_exec ( $ch ); $httpCode = curl_getinfo ( $ch , CURLINFO_HTTP_CODE ); curl_close ( $ch ); if ( $response === false || $httpCode !== 200 ) { return null ; } return trim ( $response ); } $ip = getPublicIP (); echo $ip ?? 'Unavailable' ; Use case 3 — Full geolocation data When you need country, city, ISP and timezone in addition to the IP: <?php function getIPInfo ( ?string $ip = null ): ?array { $url = 'https://ippubblico.org/?api=1' ; if ( $ip !== null ) { $url . = '&ip=' . urlencode ( $ip ); } $ch = curl_init ( $url ); curl_setopt_array ( $ch , [ CURLOPT_RETURNTRANSFER => true , CURLOPT_TIMEOUT => 5 , CURLOPT_SSL_VERIFYPEER => true , ]); $response = curl_exec ( $ch ); $httpCode = curl_getinfo ( $ch , CURLINFO_HTTP_CODE ); curl_close ( $ch ); if ( $response === false || $httpCode !== 200 ) { retur

The ScyllaDB PHP driver is not a C++ extension anymore. As of 1.4.0 it's pure C23, the ZendCPP template layer we leaned on for the object embed and allocate pattern is deleted, and the build no longer needs a C++ compiler at all. Every hand-written .cpp file is a .c file now (71 of them), the descriptor generator emits .c , and CMake builds with c_std_23 and nothing else. That's the biggest change to how this extension is built since we forked it for PHP 8.0. This is also the release where a plan I opened back in 2023 finally landed. PR #50 laid it out: rewrite the src/Cluster directory to be more maintainable, use Zend Fast Argument Parsing, remove some memory allocations, and add .stub.php files that generate the C headers so nobody has to hand-maintain Zend arginfo by hand. 1.4.0 is that plan finished, and a lot more that grew out of it. The things you'll actually feel: persistent session connect() doesn't allocate a 200-character key string on every call anymore, and the minimum PHP is now 8.3 (8.2 is gone). Nothing in your application code changes, this is almost all under the surface. The .stub.php Build The idea from PR #50 was small. Instead of writing ZEND_BEGIN_ARG_INFO_EX blocks by hand and keeping them in sync with the actual method bodies, write the signature once in a .stub.php file and generate the C arginfo from it. In v1.4.0 that's the whole build. There are 75 .stub.php files now, and each one is just the PHP signature of the class: // src/Keyspace.stub.php interface Keyspace { public function name (): string ; public function replicationClassName (): string ; /** @return array<string, mixed> */ public function replicationOptions (): array ; public function hasDurableWrites (): bool ; /** @return Table|false */ public function table ( string $name ): Table | false ; public function aggregate ( string $name , mixed ... $types ): Aggregate | false ; } At build time CMake runs gen_stub.php (vendored from PHP 8.5's build/gen_stub.php , with two small p

I released php-quic 1.0.0, a PHP extension that gives you raw QUIC transport with first-class access to streams. It links against the same OpenSSL that PHP already links against, and that is the whole trick. Why This Was Awkward Before QUIC is not a protocol you bolt on in userland. It is TLS 1.3, congestion control, loss recovery, and stream multiplexing, all riding on UDP, and all of it has to be right before you can send a single useful byte. You could get there from PHP if you were willing to bind to a foreign QUIC library like ngtcp2 or quiche through FFI. That works, but now your PHP app carries a second TLS stack, a second set of CVEs to track, a build story that involves Rust, and a version matrix that has nothing to do with the one your distro maintains. For a language whose entire deployment story is "the package manager handles it," that is a lot of rope. What Changed OpenSSL 3.5 shipped a native QUIC stack. Client and server, in the library PHP is already built against. That reframes the problem. The extension is no longer "embed a QUIC implementation into PHP." It is "expose the QUIC that is already sitting there." No new TLS stack, no FFI layer, no Rust toolchain in your build. If your OpenSSL is patched, your QUIC is patched. The requirements fall out of that directly: PHP 8.4 or newer (8.5 on Windows), NTS or ZTS OpenSSL 3.5.0 or newer, built with QUIC support Transport, Not HTTP/3 The thing I most wanted to avoid was shipping an HTTP/3 client and calling it a QUIC library. QUIC is a transport. HTTP/3 is one protocol that runs on it, and it is not the interesting one for everybody. DNS-over-QUIC runs on it. So does anything you want to invent that needs multiplexed, ordered, loss-recovered streams without head-of-line blocking across them. So php-quic hands you connections and streams, and stays out of the framing business. If you want HTTP/3, you build HEADERS frames and QPACK on top of it, and the README has a worked example. If you want something

Cross-posted from the HTML to Image blog , where the original lives. Browsershot is the package most Laravel developers reach for when they need to turn HTML into an image. It wraps Puppeteer, drives real Chrome and produces pixel-accurate output. On your machine it works first time. Then you deploy, and the first render throws Failed to launch the browser process! . The problem is not Browsershot's code. The problem is what it demands from the machine it runs on. What Browsershot actually asks of your server Browsershot is a PHP package with a second runtime hiding inside it. To run it in production you need Node.js, the Puppeteer npm package, a Chrome or Chromium binary, the long tail of shared libraries Chrome links against ( libnss3 , libatk , libgbm and friends on a slim Debian image) and a font set wide enough to cover whatever your templates contain, emoji included. That is manageable on a full VPS you control. It falls apart in the places Laravel apps increasingly run: Laravel Vapor and serverless. The PHP Lambda runtime ships neither Node nor Chrome, and you cannot apt-get your way out of a Lambda. The Puppeteer on Lambda guide covers just how deep that particular hole goes. Shared and managed hosting. No root, no system packages, no browser binary. Browsershot is simply off the table. Slim Docker images. php:8.3-fpm-alpine carries none of Chrome's dependencies. Adding Chromium, its libraries and fonts costs a few hundred megabytes and a permanent maintenance line in your Dockerfile. CI pipelines , where every job downloads a browser before your test suite can touch a render. The dependency does not stay contained either. Even Spatie's newer packages inherit it: spatie/laravel-og-image renders through laravel-screenshot , which drives Browsershot underneath, so the Node and Chrome requirement follows the whole family wherever it goes. The usual workarounds The first workaround is the fat container: bake Chromium, the shared libraries and a font stack into y

While building a Computer-Based Testing (CBT) platform, I ran into an unexpected problem. Creating mathematics and chemistry questions wasn't nearly as straightforward as I expected. Although there are many excellent editors and open-source libraries available, I couldn't find one that brought everything together in a way that was simple, lightweight, and designed specifically for CBT systems. Instead of building everything from scratch, I took a different approach. I combined several powerful open-source technologies into a single editor that focuses on one job—making it easy to create mathematics and chemistry content for online examinations. The result is CBT Editor, a free and open-source equation editor built for developers, schools, and educational platforms. It supports common mathematical expressions, chemistry notation, scientific symbols, fractions, superscripts, subscripts, and more, while remaining easy to integrate into existing projects. This project isn't meant to replace the fantastic libraries that already exist. In fact, it depends on them. The goal is to provide a clean, unified experience so developers don't have to spend hours combining multiple tools just to support technical examination questions. If you're building a CBT platform, an online examination system, or any educational application that requires mathematics and chemistry editing, I'd love for you to give CBT Editor a try and share your feedback. 🔗 Live Demo: https://holygist.github.io/cbt-editor/ Open-source software grows through collaboration. If you find the project useful, feel free to contribute, report issues, suggest improvements, or simply share it with other developers.