Coder Legion - Recent posts tagged php

PHP2Shell: When a Simple Upload Feature Turns Into Remote Code Execution

Sat, 31 Oct 2026 12:16:03 +0000

Exploring CVE-2026-109618 and CVE-2026-109619 through a TryHackMe lab.

Introduction

October is Cybersecurity Awareness Month, and honestly, this month has been quite interesting from a cybersecurity perspective. There have been plenty of vulnerabilities, attacks and security incidents worth paying attention to.

But while going through TryHackMe, something particularly caught my attention: PHP2Shell.

At first, I was interested in the upload exploitation technique. I mean, how does something as ordinary as a file upload eventually lead to remote code execution?

That question made me curious enough to investigate further.

On October 21, 2026, two critical vulnerabilities were disclosed in PHP: CVE-2026-109618 and CVE-2026-109619. Together, they demonstrated how an unauthenticated attacker could potentially execute operating system commands on a vulnerable PHP server through specially crafted HTTP requests.

And here's the part I found most interesting:

The application itself didn't even need to be vulnerable.

The weakness existed inside PHP's runtime, meaning that even an application with perfectly ordinary PHP code could potentially be affected.

So, I decided to explore the vulnerability through a TryHackMe lab and understand what was actually happening behind the scenes.

Let's break it down.

1. First, what exactly is PHP2Shell?

PHP2Shell is the name given to a pair of vulnerabilities affecting the PHP runtime.

CVE	Description
CVE-2026-109618	Remote code execution via out-of-memory (OOM) handling and request-state corruption
CVE-2026-109619	Remote code execution via stale global state and use-after-free

Both vulnerabilities received a CVSS v4.0 score of 9.2 (Critical).

The vulnerabilities involve PHP's internal request-processing and memory-management mechanisms.

What makes this particularly concerning is that the vulnerable code isn't necessarily part of the application developers write. It exists deeper inside the PHP engine.

So, updating your WordPress installation or fixing your Laravel application wouldn't automatically resolve the underlying problem.

To understand why, I first needed to understand the PHP feature involved in the exploitation.

2. The interesting part: PHP Upload Progress

The TryHackMe exploitation scenario explores PHP's session.upload_progress functionality as part of the attack path.

PHP provides this feature to track file uploads.

Imagine uploading a large file through a website. You might see a progress indicator showing how much of the file has been uploaded.

PHP can help provide this information by tracking details such as:

Uploaded file name.
Total upload size.
Amount of data received.
Current upload progress.

The relevant configuration directive is:

session.upload_progress.enabled = On

And the default form field responsible for activating this functionality is:

PHP_SESSION_UPLOAD_PROGRESS

Now, here's where things get interesting.

PHP processes this upload-progress information while parsing an incoming multipart/form-data request.

That happens before the application script actually starts executing.

In simpler terms, PHP is already processing the upload before the website's own PHP code gets control.

This means the relevant request-processing functionality can be reached without the target page necessarily implementing its own file-upload feature.

I found this particularly interesting because it changes how we think about the attack surface.

We normally think about vulnerabilities in terms of application code, authentication systems and user input validation.

3. Understanding the actual memory-management bug

This was probably the part that required the most attention from me.

To understand PHP2Shell, I needed to understand what happens when PHP runs out of memory.

PHP has a configuration directive called memory_limit, which restricts how much memory a request can consume.

When a request exceeds that limit, PHP can trigger something called a bailout.

Internally, the engine uses longjmp() to escape the current execution path after certain fatal errors.

Normally, software should clean up its resources properly when an operation finishes.

However, an emergency bailout can interrupt normal request processing and leave internal state in an incomplete condition.

This is where PHP2Shell becomes interesting.

CVE-2026-109618: Out-of-memory handling

In this vulnerability, an out-of-memory condition can interrupt PHP while request data is only partially initialized.

The bailout can leave PHP's internal request state inconsistent. When subsequent cleanup operations process that incomplete state, memory corruption can occur, potentially leading to remote code execution.

CVE-2026-109619: Stale global state and use-after-free

The second vulnerability involves a different memory-management problem.

Request-owned memory can be freed while stale global state continues to reference it.

If a later request is handled by the same worker before that state is properly reinitialized, PHP may access memory that is no longer valid.

This creates a use-after-free condition.

Why is a use-after-free dangerous?

Think of memory as a collection of storage locations.

A program allocates a location, stores information there and keeps a pointer to access it later.

Now imagine that the location gets freed, but the program still has the old pointer.

Another allocation might eventually reuse that same memory location.

The original pointer now references something different from what it was supposed to reference.

That's the fundamental problem behind a use-after-free scenario.

The Apache worker connection

The lab uses Apache with mod_php in a prefork configuration.

In this setup, an Apache worker can process multiple requests during its lifetime.

That means internal state left behind by one request can potentially affect a subsequent request handled by the same worker.

This is particularly relevant when understanding the stale-state issue in CVE-2026-109619.

So, the issue isn't simply that PHP encounters an error.

The problem is that internal memory and request state can remain inconsistent or stale in ways that influence subsequent processing.

And this is what makes the exploitation chain possible.

4. Understanding the two vulnerabilities

Now that we understand the different memory-management problems, let's look at how the two CVEs fit into the bigger picture.

CVE-2026-109618: RCE via Out-of-Memory Corruption

This vulnerability involves PHP's handling of an out-of-memory condition during request processing.

An OOM-related bailout can interrupt PHP while internal request data is only partially initialized.

Subsequent cleanup may then operate on invalid or incomplete state, potentially resulting in memory corruption and remote code execution.

CVE-2026-109619: RCE via Stale Global State

The second vulnerability involves stale internal state that survives after the memory backing it has been freed.

When a later request is handled by the same worker, PHP may access that stale state before it has been properly reinitialized.

This creates a use-after-free condition that can ultimately be exploited to achieve remote code execution.

Where the lab's memory-disclosure stage fits

In the TryHackMe exploitation walkthrough, the exploit first obtains information about the PHP worker's memory layout.

The interesting part is where this information gets returned.

PHP uses the following HTTP response header:

Set-Cookie: PHPSESSID

The resulting oversized session identifier can expose adjacent process memory.

That memory may contain useful information, including heap and library addresses.

Why does that matter?

Because modern operating systems use a security mechanism called Address Space Layout Randomization (ASLR).

ASLR randomizes memory locations to make exploitation more difficult.

An attacker generally needs to know where important functions and memory regions are located to reliably manipulate execution.

In the TryHackMe lab, the exploitation chain obtains two important addresses:

The PHP heap base address.
The libphp base address.

This information becomes useful in the next stage.

The important distinction is that this memory-disclosure stage is part of the exploitation chain demonstrated in the lab. It should not be confused with the primary vulnerability classification of CVE-2026-109618, which is remote code execution.

The HashTable and pDestructor technique

This is where things get considerably more interesting.

The lab's exploitation chain uses a forged internal PHP structure called a HashTable.

One of the important fields involved is:

pDestructor

This field is associated with the function PHP calls when destroying certain values.

The demonstrated exploitation technique manipulates this structure to redirect the cleanup process toward the system() function inside PHP's library.

Instead of executing the expected cleanup operation, PHP ends up invoking a function capable of executing operating-system commands.

And that's how the memory manipulation in the demonstrated chain can ultimately result in remote code execution.

What I found particularly interesting is that the normal cleanup process itself becomes part of the exploitation chain.

Something designed to manage resources properly can become dangerous when the underlying memory state has been corrupted.

It's worth remembering that these HashTable and pDestructor details describe the exploitation technique demonstrated in the lab, rather than a universal explanation of the root cause of both CVEs.

5. My practical investigation on TryHackMe

After understanding the concepts, I moved on to the practical investigation.

The TryHackMe room provided a vulnerable PHP server running inside a Docker container.

I connected to the machine using SSH with the provided credentials.

The first thing I wanted to do was identify the running container and check its PHP version.

I used:

docker ps --format '{{.Names}} {{.Image}} {{.Status}}'

The output showed:

php2shell-target php:8.4.26-apache Up

Next, I checked the PHP version inside the container:

docker exec php2shell-target php -v

The target was running:

PHP 8.4.26 Zend Engine v4.4.26

This was important because PHP 8.4.27 was the fixed release.

So, the lab environment was running a vulnerable version.

Inspecting the application

Next, I wanted to see what the actual website was returning.

I executed:

curl -s http://127.0.0.1:8088/index.php

The response?

OK

That's it.

I also inspected the PHP file:

docker exec php2shell-target cat /var/www/html/index.php

And found:

<?php echo "OK\n"; ?>

At this point, I found the situation particularly interesting.

There was no login system.

There was no database.

There was no application-level file-upload functionality.

The application was literally printing OK.

Yet the underlying PHP runtime was vulnerable.

This reinforced one of the biggest lessons from the room: an application doesn't necessarily need to contain vulnerable code for its underlying server to be exploitable.

6. Observing the memory disclosure

After confirming the target environment, I moved to the memory-disclosure stage.

The lab provided an existing exploit repository:

php2shell-bypass-aslr-exp

I navigated into the directory:

cd ~/php2shell-bypass-aslr-exp

The provided exploit handled the exploitation stages.

I ran it against the local target:

python3 exploit.py -u http://127.0.0.1:8088/index.php

The output showed two particularly interesting stages:

`[*] stage 1: heap leak
[+] chunk base = 0x...

[*] stage 2: libphp leak
[+] libphp base = 0x...`

These were the two memory addresses the exploitation chain needed.

The first revealed the heap location, while the second revealed the PHP library's base address.

I found this interesting because ASLR is specifically designed to make these locations unpredictable.

Instead of simply guessing the addresses, the exploitation chain obtains information about the actual memory layout.

This demonstrated how a memory disclosure stage can become a stepping stone toward something much more serious.

7. From memory disclosure to remote code execution

Now came the part I was particularly interested in: actually demonstrating command execution.

After the memory disclosure stages, the exploit proceeded to the final stage involving the manipulated HashTable structure.

The lab provided the following execution proof:

PROOF: uid=33(www-data) gid=33(www-data) groups=33(www-data)

And there it was.

The command had executed successfully under the www-data account, which is commonly used by web servers on Linux systems.

This confirmed that the exploitation chain had achieved remote code execution in the lab environment.

The next step was retrieving the flag.

The lab's exploit used the following command:

python3 exploit.py \ -u http://127.0.0.1:8088/index.php \ -c 'cat /f>/out/p1' \ --proof-file out/p1

The result returned the flag:

THM{b4ilout_l3aves_th3_h3ap_dang1ing}

THM{b4ilout_l3aves_th3_h3ap_dang1ing}

A pretty fitting flag for a vulnerability involving a bailout and a dangling pointer.

What made this practical exercise memorable for me was the fact that the target application itself never changed.

It continued to be a simple PHP page returning OK.

The exploitation happened because of the vulnerable runtime underneath it.

8. Detection and mitigation

Understanding how an attack works is one thing.

Knowing how to prevent or detect it is equally important.

Since PHP2Shell affects the PHP runtime, updating the application alone isn't enough.

The PHP installation itself needs to be patched.

The fixed releases identified in the security advisory are:

PHP branch	Fixed release
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35

Temporary risk reduction

If immediate patching isn't possible, administrators can review their PHP request-handling configuration and apply temporary defensive measures, such as restricting request-body sizes at the reverse proxy or web-server level.

Disabling session.upload_progress may also reduce exposure to the specific upload-progress attack path demonstrated in the lab:

session.upload_progress.enabled = 0

However, these measures are only temporary risk-reduction steps. They do not fix the underlying vulnerabilities and should not be considered complete mitigations.

The only safe solution is to update PHP to a fixed release.

After updating, restart PHP-FPM workers or reload/restart Apache when using mod_php.

If PHP runs inside containers, rebuild or replace the affected containers so that no vulnerable runtime instances remain.

What should defenders monitor?

Some suspicious indicators worth investigating include:

Unusually large PHPSESSID values in Set-Cookie response headers.
Suspicious multipart POST requests.
Unexpected PHP worker crashes.
Memory exhaustion errors.
PHP processes unexpectedly spawning shell processes.
Unusual command execution under the web server account.

One important lesson here is that monitoring only the application layer isn't sufficient.

Because the vulnerability is triggered during PHP's internal request processing, detection and prevention need to account for activity happening before the application script executes.

Patching the runtime remains the priority.

9. What I learned from this investigation

This was more than just another TryHackMe room for me.

It helped me connect several concepts that I had previously encountered separately.

Some of the things I explored included:

How PHP processes multipart/form-data requests.
What session.upload_progress actually does.
How memory allocation and dangling pointers work.
Why an out-of-memory bailout can become dangerous.
What ASLR does and why attackers try to bypass it.
How memory disclosure can assist remote code execution.
How PHP's internal cleanup mechanisms can become part of an exploitation chain.
Why securing the application doesn't necessarily secure the runtime.

But there's one thing that stood out above everything else.

Sometimes, the vulnerability isn't in the code you wrote. It's in the code your code depends on.

As someone learning cybersecurity alongside software development and AI/ML, I find these investigations particularly valuable.

I don't want to simply learn which command executes an exploit or how to retrieve a flag.

I want to understand what happens underneath, why a vulnerability exists, how it can be abused and, most importantly, how defenders can prevent it.

Because there's a difference between knowing that something works and understanding why it works.

And I'm genuinely enjoying the process of learning that difference.

Final thoughts

PHP2Shell was a great reminder that cybersecurity isn't just about finding vulnerabilities in websites.

It's also about understanding the technologies, runtimes, libraries and systems that make those websites work in the first place.

A seemingly harmless upload-progress feature, combined with a memory-management failure, demonstrated how something deep inside a runtime could eventually lead to remote code execution.

And that's what makes cybersecurity so interesting to me.

There's always another layer to investigate, another question to ask and another mechanism to understand.

Stay curious. Keep learning. Keep breaking things in controlled environments, and most importantly, understand what you're doing.

Disclaimer: This investigation was conducted in an authorized TryHackMe lab environment. The exploit and command-execution results described above relate to that controlled environment.

PHP2Shell: patch PHP now, then check

Fri, 30 Oct 2026 19:55:54 +0000

Originally published on the Dunime blog.

Two critical PHP flaws let an attacker run code on a web server without logging in. What changed on 21 October, which sites it touches, and what to do today.

If a website runs on PHP, it is in scope. On 21 October 2026 the PHP project shipped fixes for two critical flaws that can let an unauthenticated attacker run code on the web server, and said that updating is the only complete fix.

What changed

On 20 October the PHP security team gave advance notice of a release fixing two critical vulnerabilities, both rated CVSS v4.0 9.2. On 21 October it published PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 with a security advisory headed "update now". The pair is widely reported under the name PHP2Shell.

CVE-2026-109618, code execution via out-of-memory corruption: out-of-memory handling can interrupt PHP while internal request data is only partly set up, and request cleanup may then treat that invalid data as valid.
CVE-2026-109619, code execution via stale global state: internal state belonging to one request can survive after its memory has been freed, and a later request handled by the same worker may use it.

In PHP's words, there are no complete mitigations and updating is the only safe choice. On 23 October PHP added an informational note: keep session.upload_progress.enabled=0 until the next regular bugfix release, to close an unlikely related vector it will document as CVE-2026-115560.

On exploitation: BleepingComputer reported on 21 October that Cloudflare's CTO said the company was already observing early attacks against both flaws before the patches shipped. The UK NCSC alert of the same day asks organisations to update immediately; it does not itself state that the flaws are being exploited.

Who it applies to

PHP's advisory puts every PHP installation that serves web requests at risk: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It rates the risk highest for mod_php, where a demonstrated exploit lets an unauthenticated request trigger the attack before any application code runs.

CMS and web apps: WordPress, Drupal, Joomla, Magento, phpMyAdmin and Nextcloud all run on PHP. Help Net Security, reporting Searchlight Cyber's research, names all six as software on which exploitation has been confirmed. A fully updated plugin or theme does not help if the PHP underneath is unpatched.
Shared hosting and cPanel: on shared hosting the provider usually owns the PHP build. The PHP version picker in the panel shows which branch a site uses, but whether that build carries the 21 October fix is the host's answer to give.
Old PHP: PHP 8.1 and older no longer get updates from the PHP project. Some Linux distributions and long-term-support vendors backport fixes, so ask the vendor. PHP also published minimal source backports for 7.4, 8.0 and 8.1 for people who build from source. PHP 8.2 itself reaches end of life on 31 December 2026.
Agencies and IT teams: anyone who runs sites for others owns an inventory problem today. The NCSC asks for discovery of every PHP installation, internet-facing first, and warns not to limit the search to outdated PHP versions.

Patching the plugin is not patching PHP.

What to do today

1. Find every PHP install. Start with internet-facing sites, then internal tools. Include appliances and products that bundle PHP, and apply their vendors' updates as they arrive.
2. Check the version. On a server, php -v shows the command-line build. The web server can run a different build, so also check the hosting panel or your package manager. Distribution packages may carry the fix under their own version numbering, so confirm with the vendor's security notice rather than the number alone.
3. Update. Move to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or the patched package from your distribution or LTS vendor, internet-facing systems first. Restart PHP-FPM or Apache so every worker runs the new build.
4. If you cannot update yet, reduce exposure. PHP's interim measures narrow specific attack paths but do not make a server safe. They are listed in the next section.
5. If even that is not possible: the NCSC says to consider taking the system offline until it is fully mitigated, and, if it cannot be updated or disabled straight away, to check it for signs of compromise and backdoors first.
6. Check the logs. Look for new or changed PHP files in upload and cache folders, unexpected admin accounts, and bursts of large multipart POST requests, memory-exhaustion errors or crashed PHP-FPM workers. A server that was exposed before patching should be checked, not just patched.
7. Know who to call. Your hosting provider for the PHP build, your application vendor for bundled PHP, and an incident response team if you find signs of compromise. In India, cyber incidents are reported to CERT-In.

Interim mitigations PHP published

Only for systems that cannot be updated immediately. PHP is explicit that these reduce exposure to specific attack paths and do not make an installation safe.

For CVE-2026-109618: set memory_limit=-1 in a way applications cannot override, such as php_admin_value in the FPM pool or Apache configuration, and check nothing sets a finite limit back. Set a low post_max_size: 8M for applications without file uploads, 32M if uploads are needed, with upload_max_filesize below it. Use a container or cgroup limit, ideally one that kills only the affected worker; PHP warns not to substitute RLIMIT_AS or RLIMIT_DATA.
For CVE-2026-109619: set session.upload_progress.enabled=0 in php.ini, the FPM pool or server configuration (not ini_set() or .user.ini) and restart every worker. On PHP 8.5, also set fatal_error_backtraces=0 and restart. Remove invalid or deprecated per-request settings that emit diagnostics, and fix fatal errors and timeouts an attacker can reach.
What does not help: hiding errors with error_reporting, display_errors or the @ operator.

A free scanner, and its catch

On 22 October Searchlight Cyber released php2shell-scanner, a free, open-source command-line tool (github.com/assetnote/php2shell-scanner) that tests whether a host shows the vulnerable behaviour rather than only reading a version number. It first tries to produce a PHP memory-exhaustion error, then looks for a PHP-FPM worker dying mid-request, and only as a last resort reads the advertised PHP version.

The catch: detection deliberately pushes PHP into an out-of-memory condition. The researchers call this "fundamentally risky in nature" and ask for care and caution. Each tested path can receive a small control request and three probes totalling about 29 MiB.
False positives: the README warns that a patched build can return the same empty HTTP 500 when a probe exceeds a low memory_limit, so check any "vulnerable" result against the installed version and vendor backports.
Run it only on systems you own or are authorised in writing to test, and in a maintenance window. It is a check after patching, not a reason to delay the patch.

Questions people ask

What is PHP2Shell? The name widely used for CVE-2026-109618 and CVE-2026-109619, two critical PHP vulnerabilities fixed on 21 October 2026 that can allow unauthenticated remote code execution on web servers running PHP, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed.

Which PHP versions fix PHP2Shell? PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older no longer receive updates from the PHP project; some Linux distributions and LTS vendors provide backported fixes, and PHP published minimal source backports for 7.4, 8.0 and 8.1.

My WordPress site is on shared hosting. What should I do? Check the PHP version in your hosting panel and ask your host whether their PHP build includes the 21 October 2026 fixes. Updating WordPress, plugins and themes does not fix PHP itself. If the host cannot confirm, ask when it will, and follow the NCSC advice for systems that cannot be patched.

Sources

Dunime maps live threats like this one to the specific checks and defences that answer them: dunime.com/now.

Not sure what's exposed? Dunime's VAPT checks whether unpatched services like this are reachable and exploitable across your estate.

Published by Dunime Technologies — custom software, automation and cybersecurity, Delhi NCR, India.

WordPress Crash Recovery & Plugin Conflict Resolution

Fri, 30 Oct 2026 14:36:25 +0000

When a WordPress site crashes immediately after an update, the immediate business impact is lost revenue, disrupted customer workflows, and compromised search standing. In production environments, standard advice like "restore a backup from yesterday" can cause critical data loss: orders placed between the backup and the crash, customer registrations, and recent transactions vanish.

A disciplined engineering approach treats a crashed WordPress site as a contained system failure: isolate the execution failure, restore availability, fix the root cause, and verify data integrity before returning traffic to normal operations.

Common Crash Failure Modes After Updates

WordPress crashes after updates typically stem from four discrete architectural failure modes:

PHP Fatal Errors (Type Errors & Deprecations): A plugin update requires PHP 8.1+ syntax or library extensions that conflict with the server runtime or an older theme calling deprecated functions.
Hook and Filter Signature Conflicts: Two active plugins hook into the same action (e.g., woocommerce_checkout_order_processed or template_redirect) expecting incompatible argument types or returning invalid objects.
Database Schema Migrations & Locked Tables: Complex plugins (WooCommerce, membership tools, custom post-type managers) execute DDL migrations upon activation. If a migration times out or hits MySQL lock contention, queries fail across the application.
Autoloaded Options & Memory Exhaustion: Plugins accumulating transient data in wp_options with autoload = 'yes' spike PHP memory usage beyond memory_limit, triggering fatal out-of-memory crashes on high-concurrency requests.

Systematic Diagnostic Protocol

When diagnosing a crashed WordPress production instance, follow this 5-step engineering triage:

Step 1: Capture Raw Error Logs Without Exposing Stack Traces

Do not enable WP_DEBUG_DISPLAY on a live production URL. Instead, enable debug logging to a private log destination:

// In wp-config.php (before /* That's all, stop editing! */)
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', '/var/log/wordpress/debug.log'); // Secure path outside public web root
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', '0');

Inspect debug.log or the web server error log (NGINX/Apache/FPM error log) to identify the exact file, line number, and exception stack trace.

Step 2: Safe Plugin Isolation via WP-CLI

Avoid renaming the entire wp-content/plugins folder if possible, as this deactivates all plugins and breaks widget and database mappings upon reactivation. Use WP-CLI to isolate the culprit:

# Check status of installed plugins
wp plugin list --status=active

# Deactivate the suspect plugin identified in the error stack trace
wp plugin deactivate offending-plugin-slug --skip-plugins --skip-themes

# Verify frontend HTTP response code
curl -I https://example.com

Step 3: Check MySQL Database Integrity and Migration Locks

If the error indicates missing tables or broken queries, verify table health:

# Check and repair WordPress core and plugin tables
wp db check
wp db repair

# Identify oversized autoloaded options causing memory exhaustion
wp db query "SELECT option_name, LENGTH(option_value) AS size FROM wp_options WHERE autoload='yes' ORDER BY size DESC LIMIT 10;"

Step 4: Patch Compatibility or Pin Version

If the site requires the updated plugin for business operations, evaluate whether a targeted patch (e.g., handling a null object check in a template hook) or a clean version downgrade via WP-CLI is appropriate:

# Safely roll back to previous known-stable version
wp plugin install offending-plugin-slug --version=2.4.1 --force

Step 5: Verification and Regression Testing

Verify that critical customer journeys work end-to-end:

Homepage, archive, and single post rendering
User authentication and session persistence
E-commerce cart, checkout, and webhook callbacks
Scheduled cron tasks (wp cron event list)

When to Seek Engineering Assistance

If a WordPress crash involves corrupted database transactions, custom plugin architecture conflicts, security compromises, or legacy codebase friction, contained engineering intervention restores stability safely.

For rapid assistance with an active failure or production regression, see WordPress & website bug fixing or queue an urgent bug fix. To prevent update regressions entirely with weekly staging tests and daily backups, explore the WordPress Care Plan. If your platform requires broader architecture stabilization, review SazM's Diagnostic Audits or start a direct technical inquiry at the contact page.

Originally published with full diagnostic protocols at SazM: WordPress Crash Recovery & Plugin Conflict Resolution.

php2shell: two ways PHP corrupts its own memory, and why turning that into a shell is still hard

Fri, 30 Oct 2026 13:40:16 +0000

A single unauthenticated request can run code as your web worker on PHP before 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35. The bug is real, the patch is out, and reliable exploitation outside a lab is far harder than the headlines suggest. This is the full analysis, and an honest account of how long it took to prove (and why so long).

Lab-only research on a patched vulnerability. Knowledge sharing, not a how-to.

If you read nothing else, do these five things

Upgrade now to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35. These fix CVE-2026-109618 and CVE-2026-109619. On an end-of-life branch, do not hand-apply an isolated source patch on top of the last EOL release: it closes these two CVEs but leaves you exposed to everything else fixed since the branch went out of support. Get a maintained build from your distro or a package maintainer (Ondřej Surý's deb.sury.org, Remi Collet's repo, Red Hat's module streams), which carry patched builds reaching back through 5.6, or upgrade. Check the package changelog for the CVE IDs before you trust any build. On Windows, take the -1 rebuild (8.5.12-1 and friends): that one bundles a separate Brotli 1.2.1 fix for CVE-2026-111497, an out-of-bounds write reachable through the cURL extension when automatic response decompression is on. Different bug, same download.
Set session.upload_progress.enabled=0, and turn off every extension and feature you don't use. The session flag is PHP's own published mitigation. The general habit, shrinking the attack surface, is the part that pays off on the next bug you haven't heard about yet.
If you run mod_php, move to php-fpm. The FPM process model removes an entire class of these chains and isolates workers from the web server. It raises the bar. It does not close the door: I got a shell on FPM too.
Exploiting this in the wild is hard. Not impossible, hard. Every chain is calibrated to one exact build, the heap grooming is fragile, and even with current LLMs doing the heavy lifting it took days of dead-ends to reach a reliable shell. Sansec and Wiz have both reported public "php2shell" PoCs that do not work against a default install.
This article explains the mechanism and the mitigations. It is not a copy-paste exploit kit, and the working lab harness targets the vulnerable 8.5.11 image only.

Credit where it is due

Discovery and analysis: Calif and Wiz. Their public write-ups, along with the PHP source patch, are what let me understand the issue well enough to reproduce it. If you want the discovery story and the wider impact catalogue, read theirs first.

The fix: the PHP team. "Avoid state corruption via bailout", authored by Arnaud Le Blanc, Ilija Tovilo, Jakub Zelenka, Nora Dossche, and Nicolas Grekas. They turned a messy memory-corruption class into a two-line conceptual fix: stop using zend_bailout on OOM, and reset the globals that startup touches.

Review: special thanks to Arnaud Le Blanc for reviewing an early draft and giving sharp, generous feedback that made this write-up more accurate.

Why this wasn't Log4Shell

The response was loud. NSA, the FBI, and the UK's NCSC all told anyone who could not patch immediately to take the affected system offline until it was mitigated; CISA said the same in its October 24 update, and days earlier had reported active exploitation and added both CVEs to its Known Exploited Vulnerabilities list. I would take the "active exploitation" label with a grain of salt. In waves like this, what gets reported as exploitation is often mass scanning and failed attempts. More than one vendor has quietly walked back a confident "actively exploited" claim once someone checked whether the traffic was a scan or a real shell, and this is not a bug that falls to a generic payload. The PHP team never called for shutting servers down. Their guidance was to patch, then apply the config mitigations.

Everyone reached for the Log4Shell comparison. So why wasn't the whole internet on fire? Why targeted hits instead of a mass, worming wave? The answer is in the offsets, and it is the reason this write-up exists.

The root cause: PHP panics by longjmp, and panic skips cleanup

When a PHP request exhausts memory_limit, the engine historically raised a fatal error and recovered with zend_bailout(), a longjmp back to a safe point. That unwind is the problem. A longjmp does not run the cleanup that a normal return would. If the allocation failed halfway through building a data structure, the half-built structure survives, and a global still points at it.

Both CVEs are that same mistake, caught in two different places.

CVE	What it is
CVE-2026-109618 · Bailout state corruption	An OOM during request startup, request parsing, or session handling leaves engine globals pointing at freed or half-initialized memory. The next request on the same worker inherits the mess.
CVE-2026-109619 · Pre-RINIT decode reuse	The upload-progress feature decodes a session before the request re-initializes its globals. With the unserializer left in a dirty state by a prior OOM, that early decode reuses a dangling structure.

The patch stops the OOM from longjmp-ing mid-operation. It defers the out-of-memory error and raises it at controlled chokepoints, an uncatchable UnwindExit while a userland frame is on the stack, and resets the globals that startup reads. 389 files changed, and a pile of new oom_rfc1867_*.phpt tests pin the exact spots where an allocation could fail mid-structure. On the supported branches an ordinary memory_limit hit is now a graceful fatal that still runs shutdown handlers; only a request that blows past a new hard ceiling, 200% of memory_limit, forces the process out with _exit(137). That rework did not reach the out-of-support branches: the fixes carried by distros and maintainers for 7.4, 8.0, and 8.1 take the blunt route and simply _exit(1) on the offending allocation, tearing the whole process down rather than attempting the unwind that caused the bug. Either way, the corrupting bailout is gone.

The primitive: one signed integer turns a session into an arbitrary write

Everything downstream rests on one function in the unserializer. var_tmp_var() hands out scratch slots from a block of destructor entries. It reads how many slots are used, then returns a pointer past them:

// ext/standard/var_unserializer.re  (simplified)
static zval *var_tmp_var_num(php_unserialize_data_t *var_hashx, zend_long num) {
    var_dtor_entries *var_hash = (*var_hashx)->last_dtor;
    ...
    zend_long used_slots;           // <-- SIGNED
    for (used_slots = var_hash->used_slots; ... )
        ZVAL_UNDEF(&var_hash->data[used_slots]);
    return &var_hash->data[used_slots];   // base + used_slots*16
}

used_slots is a signed zend_long. Make it negative and the returned pointer lands before the block, anywhere the attacker can reach. The session decoder then writes the parsed value through that pointer, one 8-byte value plus its type tag per session variable. Control where the block sits and what used_slots holds, and you have a controlled write with controlled data.

With that write, you build a lie: a chunk of memory that PHP believes is an array. The only field that matters is the array's destructor pointer. Aim it at the internal handler for system(), and the moment PHP tears the "array" down, it runs your command.

PHP's array teardown calls pDestructor(&bucket). Overwrite that one pointer with the address of zif_system, put the command where the bucket points, and freeing the array is a shell.

From one write to a shell: the four-request mod_php chain

A single write primitive is not a shell. You still need to know where to write, which means defeating ASLR, and you need something that turns a write into execution. The mod_php chain does both across four requests on one persistent Apache worker. It is pure HTTP. No files on the target, no debugger, no application code. The chain scripts live in off_chain/.

The payoff in B2 is a classic one: a fake PHP array whose destructor pointer is the internal handler for system(). When PHP tears the array down, it calls that "destructor" with attacker-controlled data, and the command runs as www-data.

$ cat out/proof
uid=33(www-data) gid=33(www-data) groups=33(www-data)

Without the leak, every address is a guess, and a guess on a 64-bit ASLR heap is not an exploit. The forged zend_string read in B1 is what makes the rest deterministic.

The leak needs no local access. It rides out on a header the server sends unprompted: when PHP starts a session it writes the session id verbatim into Set-Cookie: PHPSESSID=.... That id is a zend_string, and B1 controls which one.

A1's bailout freed the session-id buffer but left send_cookie=1 and the dangling PS(id) pointer in place. B1 reclaims that freed chunk with a crafted multipart field and overwrites it with a fake zend_string header: a benign refcount and type word, hash zero, and a len field widened to 2048. The character data is left pointing at the surrounding chunk. When the END cleanup emits the cookie, PHP copies len bytes starting from that pointer, so the PHPSESSID value becomes a 2 KB window of live engine memory rather than a 32-character id.

Everything after that is parsing on the attacker's side. parse_leak.php URL-decodes the cookie, walks it in 8-byte steps, and keeps the qwords that fall in the heap range. The pointer that recurs with its low 12 bits equal to 0x7a0 is zval_ptr_dtor, so libphp base is that value minus 0x7b47a0; bucketing the rest by 2 MB chunk recovers the main heap base. Two reads off one response header, and ASLR is gone from outside the process.

Six paths, two execution models, one scorecard

The same primitive reaches code execution through several routes. They are not equal. Some are pure HTTP, one still needs a debugger, and the FPM and mod_php models behave very differently under the same bug. Every path's exact container setup and commands are in RCE_PATHS.md.

Path	Model	What it is	Result
A	mod_php	Four-request chain, `display_errors=On`	shell
B	mod_php	Same chain, stock `php.ini-production`. Pure HTTP.	shell
B2	mod_php	Path B with a `popen` ROP stack instead of a direct call	shell
C	php-fpm	Session-decode reuse, app-visible leak, ASLR on	shell
C2	php-fpm	Path C fired through a `popen` ROP pivot, no forged `execute_data`	shell
E	mod_php	Multipart partial-bucket teardown (path1)	crash is HTTP-only; no native leak and the groom is blocked, so the write needs an external leak or a debugger

Why FPM is the harder target

mod_php runs PHP inside a long-lived Apache worker that shares the server's address space and survives across requests. That persistence is exactly what the four-request chain feeds on. php-fpm exits the worker the moment php_request_startup() fails, so the whole startup-failure class, including path1, simply cannot carry to a second request there. FPM is the more resilient model, and moving to it is good advice.

It is not a fix. The session-decode reuse (Path C) lives in exactly the pre-RINIT window FPM still has, and I landed a clean uid=33 on a stock FPM container. FPM falls two independent ways, in fact: the forged-frame route above, and a data-only variant (Path C2) that carries no fake execute_data at all. It overwrites the destructor with a jump_fcontext stack pivot into a short popen ROP chain, and fires it through the upload-progress hash update's own old-value destructor rather than the teardown. Same leak, same reuse, no forged frame. "Harder" is the honest word. "Safe" is not.

FPM kills the worker on a failed request startup, which is what blocks the mod_php chains. Path C slips through anyway: the upload-progress decode runs before RINIT resets the worker, so request A's dangling d is still there for request B to reuse and overwrite with the same fake-HashTable frame. That pre-RINIT window is CVE-2026-109619.

One more piece of honesty about the FPM result. The mod_php chains run out of memory at the stock 128 MB limit, driven by the request itself. Nothing on the target has to cooperate. The FPM chains here lean on a lab endpoint that hands back the pointer leak and, for determinism, sets memory_limit to 4 MB with ini_set() so a 1 MB session decode is enough to OOM. The 4 MB is a lab convenience, not a requirement. The arming OOM reaches the real 128 MB limit: a session record that declares a huge array count makes the deserializer pre-allocate the whole bucket table, 128 MB from under 5 MB of input, before it parses one element. The constraint the easy framing misses is where the OOM lands. It has to fire inside the session decode, so php_var_unserialize_destroy() is skipped and the context dangles. An ordinary base64 or image-resize OOM in application code aborts in the wrong place and arms nothing. So the FPM chain needs three things from the target, not one: the pointer leak, an OOM inside session deserialization, and attacker-influenced session content to carry that record. Stock PHP hands over none of them, and the leak is still the hardest.

A reader flagged that my FPM lab spoke FastCGI straight to php-fpm, a shortcut, not a requirement. So I reworked the lab to do it properly; the repo ships that path now: the same leak and write travel the full route over plain HTTP through a stock nginx with php-fpm unreachable from outside, and still land uid=33, roughly 6 fresh workers in 10, every miss a clean retry. The FPM result is remote through a normal reverse proxy, not an artifact of reaching php-fpm directly.

What I did leave on the table, deliberately, were routes that lean on an application weakness. If the target calls unserialize() on attacker input the primitive is one request away, but the PHP manual has warned for years that unserializing untrusted input gets you hacked. That is object injection, the application's bug, not PHP's. I wanted the vulnerability shown in core PHP on a stock install, through mechanisms every install ships, not against someone's vulnerable code.

The barrier the PoCs skip: every stage needs the same worker

The chains above share a requirement the lab quietly satisfies. All four requests have to hit the same PHP worker, because the corrupted state the exploit builds lives in that one worker's memory. With a single worker that is free, and a single worker is where I started. On a production server, with a pool of workers behind a load balancer, landing four requests in a row on one specific worker looks like the hardest part of the attack.

In the lab: one worker (apache2 -X, or a single FPM child). Every request lands on it, so the state carries for free. This is where most public PoCs quietly live, and it is not a real deployment.

In production: many workers, a load balancer in front, other clients in the mix. The four stages scatter across the pool, and the state built on one worker is invisible to the next.

The obvious fix, HTTP keep-alive to pin one connection to one worker, does not work here. The chain OOMs twice on purpose, and PHP closes the connection on a bailout: the response is HTTP/1.0 500 ... Connection: close even when the request asked to keep the socket alive, and the next request on it gets EOF. I confirmed it is the SAPI bailout handling and not an unread body: a plain fatal error and a script-level OOM both close the socket the same way. Keep-alive carries a chain of healthy 200s. It cannot carry a chain whose whole point is to run out of memory.

What does work, in the lab, is process pinning: hold every worker but one busy with slow, half-sent requests, so the single free worker serves all four stages. I got this to a clean shell on mod_php, 9 of 10 prefork children pinned, and on php-fpm, 3 of 4 workers pinned with truncated FastCGI records. Both landed uid=33.

Pinning in a lab is one thing. Against a live server it is the noisy option: other clients hit that free worker too, you rarely know how many workers there are, and a fleet of half-sent connections is the shape a WAF or a bored load balancer drops. But pinning turned out to be unnecessary. Behind a stock-default nginx the php-fpm workers share one listen socket and the kernel hands new connections out in a strict round robin, so on a quiet pool the attacker never lands four stages on one worker: they walk the whole pool. Prime every worker, leak every worker, prime again, fire every worker. That is 2N ordinary complete requests for a pool of N, no slow bodies, nothing held open. I ran this end to end through a stock nginx with php-fpm unreachable from outside, on pools of 2, 4, and 8, and it landed uid=33 on every pool. Live traffic perturbs the round robin and I have not measured the hit rate under load, so this is not a one-shot against a busy server. But it refutes the idea that a worker pool behind default buffering is itself a defense. The barrier that actually holds is the next one.

Every number is build-specific

This is why the public exploits don't work on your server. The chain is a list of offsets, and every one of them is pinned to a single compiled binary. Change the PHP build, the distro, or the CPU architecture, and they all move. A PoC calibrated on the author's machine is a crash on yours.

Offset	x86-64	aarch64 (52-bit VA)
mod_php `zval_ptr_dtor`	`libphp+0x7b47a0`	`libphp+0x761b80`
mod_php `zif_system`	`libphp+0x5996e0`	`libphp+0x5314f0`
user-pointer range	`0x700000000000` to `0x800000000000`	`0xf00000000000` to `0x1000000000000`
`BG(unserialize).data`	`bg+0x368`	`bg+0x348`
fpm leak: `BASE` (from leaked pie_ptr)	`pie_ptr - 0x7c9777`	`pie_ptr - 0x6e7810`

I ported the two leak-based paths from x86-64 to a stock ARM server and both worked: the mod_php chain gave a shell in 4 runs out of 5 across randomized ASLR bases, and the FPM chain in 3 out of 3. That port did not need new exploitation ideas. PHP's internal struct layout and allocator bin sizes are identical on 64-bit ARM, so the small-bin spray and the heap grooming carried over untouched. What changed was a short list of symbol offsets and one pointer-range constant. The leak absorbs the rest, because it reads the current build's addresses at run time instead of hardcoding them. The full re-derivation method is in PORTING.md.

The fixed-address FPM variant, and why I left it out

There is a sixth route I built early and then abandoned: an FPM type-confusion that hardcodes every address instead of leaking one. The worker runs under setarch -R with ASLR off, so the PIE base and the reclaimed unserialize buffer d sit at fixed addresses across runs. Two files carry the whole exploit: a session blob sess_T whose values are d-relative pointers into a fake var_dtor_entries table, and a fill payload fillU.bin that sprays that table into the freed block so the signed-used_slots write lands on a crafted HashTable. No leak, no second request to parse one. On the exact build it was tuned against, it drops a shell on the first try.

It is also the only path I could not reproduce on a clean official image. Nothing about the bug changed; the heap did. On the freshly pulled php:8.5.11-fpm the reclaimed d came back 0x495000 away from the address baked into sess_T, so every d-relative pointer in the payload aimed into unmapped memory. Re-deriving d was not enough. The fill groom itself mis-landed: the spray reclaimed the d allocation as its own zend_string, which put the string's length word (0x1fea, 8170) exactly where last_dtor lives at d+0x10, and var_tmp_var then dereferenced 8170 as an entry count and faulted. The fixed address was not stale, it was occupied by the wrong object.

Fixing that is pure allocator choreography with no new capability at the end of it: re-derive d under the probe, rebase every pointer in sess_T and fillU.bin onto the new base, then re-tune the fill part size and count until the reclaim lands on the freed var_dtor_entries block instead of on d, and repeat for the next image release. Path C reaches the same FPM worker with a live leak that reads the current base at run time, so it absorbs all of this for free and ported to ARM with constant edits only (3 shells in 3 runs). The fixed-address variant demonstrates nothing Path C doesn't and breaks on every rebuild, so I left it out of the paths I stand behind. I am keeping the artifacts only as a worked example of how a build-specific heap groom decays, which is the real lesson: an offset is a fact about one binary, not about the bug.

Mitigations, mapped to what they actually buy you

Action	What it does
Upgrade to 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35	Removes both CVEs at the source: no more bailout corruption, no more dirty-state reuse. This is the fix; everything below is defense in depth.
Windows: the `-1` rebuild	Adds Brotli 1.2.1 for CVE-2026-111497, a separate cURL-reachable OOB write. Same PHP runtime, updated dependency.
`session.upload_progress.enabled=0`	Removes the pre-RINIT session consumer the FPM and mod_php session chains rely on. PHP's own stopgap. Does not touch path1.
mod_php → php-fpm	Removes the startup-failure class and isolates workers. Not a cure.
Disable unused extensions and settings	The habit that pays on the next unknown bug. Every decoder you don't load is a decoder that can't be confused, and the same goes for INI switches you do not need: turn off `cgi.fix_pathinfo`, `expose_php`, and any feature your application never uses.
Confine the worker (AppArmor / SELinux / seccomp)	A profile that stops the PHP worker from spawning a shell blocks the `system()` payload, and it bites where `disable_functions` cannot: this bug calls the internal handler by address, so `disable_functions` is bypassed (I confirmed it fires with `system` disabled). Docker makes a tailored profile cheap to apply, though the default Docker profile still allows shell exec. Defense in depth, not a cure: a worker running attacker code can still `readfile()` your `.env`, keys, and source through PHP and hand them back in the response, no shell needed. Only the upgrade removes the bug.

How this was done, honestly

A closing note on the effort, because the "hard even with LLMs" line up top deserves receipts. This is the story of actually building the thing, dead-ends and all.

I did not find this bug, and my first swing at it missed. The night before the patch I heard about it and spent a few late hours trying to reason it out. I got as far as the two parts that matter, a longjmp on OOM and memory_limit, and then told myself the wrong story. I was certain it had to route through serialization and the internal flags around it, so that is where I dug, and that is where I stayed stuck. Some of the information floating around online pointed the same wrong way, and I took it at face value. I'll blame the late hour rather than look too hard at my own incompetence 😆.

Then the patch landed, the shape of the thing got clearer, and the OCD kicked in. I wanted the full what, why, and how, so I set out to reproduce it end to end. The process was deliberate. I wrote up my own analysis first, a long guide and prompt laying out my theory of where the bug lived, how to reproduce it, and the path from there to a shell, then handed the exploration to DeepSeek V4.1 Flash 1017, under one firm rule: when it got stuck or unsure, it stopped and asked me how to proceed instead of guessing. At the dead-ends I gave direction and, a few times, code. We iterated over several days. Whole approaches looked right and went nowhere. The model was a regular, non-abliterated release. No jailbreak, no uncensored fork. A mainstream aligned model, pointed at a patched vulnerability, with a human in the loop the whole way.

The final validation and this write-up were mine, with Claude Opus. That last mile was the real test of the "hard even with LLMs" claim in the TLDR. Getting a shell on a known-vulnerable container is one thing. Getting the same chain to fire reliably, re-deriving every offset by hand for a new build, porting it from x86-64 to an ARM machine, that is where the days went. The AI accelerated the work. It did not trivialize it.

One more thing on the effort, because it matters. I am a PHP core developer. I have been release manager for over 20 PHP releases, I know my way around the engine internals, and I have spent years on the security side. I am not a neophyte poking at a black box, and it still took days of guided work, wrong turns, and hand re-derivation to reach a reliable shell. So when someone tells you they typed "find me an exploit" into a chatbot and out came a working php2shell chain, they are, quite frankly, full of shit. The prompt is not the hard part. The offsets are.

What this bug is, and what it isn't

php2shell is a genuine unauthenticated RCE, and if you run an unpatched PHP you should treat it as one and upgrade today. It is also a reminder that the distance between "a bug exists" and "a stranger owns your box" is measured in offsets, heap state, and days of patient grooming. The patch deletes the bug the whole path is built on, so there is no path left to walk. That is the only outcome that matters. The researchers who found it did the hard part; the PHP team shipped the fix fast; and the footnote is that even with a capable model doing the grinding, turning this into a reliable shell was work. That gap is not a reason to relax. It is why the upgrade is the whole answer.

Corrections welcome

This gets more accurate when people who know more poke holes in it. If I missed a path, botched an offset, or told the story wrong, tell me: email [*Emails are not allowed*](mailto:Emails are not allowed), DM me on X at @iliaa, or find me in the usual Discords :P.

Reproduction harness, per-path notes, and the full offset tables live in the companion repository, github.com/iliaal/php2shell, which targets the vulnerable 8.5.11 images only. Patched releases are the control in every test.

Seventeen Seconds to Parse One Name: A Security Scan Across Eleven PHP Projects

Tue, 27 Oct 2026 13:32:42 +0000

This is a 16 KB name:

$row = 'Smith, ' . str_repeat('V ', 8188);
(new \Iliaal\NameParser\Parser())->parse($row);

On nameparser 1.5.0, the last version before the fix, that call takes 17.4 seconds of CPU on my i9-13950HX. On 1.7.0 it takes 0.064 seconds. Each V is a candidate roman-numeral suffix, and the old suffix scan walked back over every earlier token for each one, so the cost grew with the square of the input. Nothing about it is exotic. It is a plausible shape for a junk row in a CSV import, and it pins a PHP worker for as long as the row keeps coming.

I didn't find it. A security scan did, and the same scan ran across all ten of my PHP extensions as well. In the first three weeks of October each project got a full pass: one coordinating session, a set of subagents reading code and writing proof-of-concept exploits, and a separate verifier that re-ran every finding before it counted, on its own ASan and release builds for the C code. Everything below ships in releases from the last few weeks.

Two other things landed in the same window. PHP's October security releases changed what memory_limit does, which forced code changes in three extensions and a same-day round of re-releases in five more. And DuckDB 2.0 went GA; pdo_duckdb bundles it as of today.

What the scans found, and what is fixed

Every project in the table has a release that carries its fixes. The counts are findings confirmed by the verifier, fixed, and released; severities are the verifier's, not the scanner's first guess.

Project	Fixed in	Confirmed and fixed
phpser	0.7.1	19: 1 high, 5 medium, 13 low
mdparser	0.8.0	12: 1 high, 5 medium, 5 low, 1 informational
fastchart	1.8.0	15 reproduced, highest medium, including vendored plutovg and plutosvg; two UBSan sites in vendored code only partly addressed
php_clickhouse	0.13.0	1 high, 1 medium, plus low-severity binding fixes and 7 server-triggered crashes in clickhouse-cpp
pdo_duckdb	0.8.0	6: 1 high, 1 medium, 1 low-medium, 2 low, 1 informational
fastjson	0.10.0	4: 1 medium, 3 low, plus 1 documentation correction
php_excel	2.9.0	5: 3 low, 2 informational
statgrab	2.3.0	4: 2 medium, 2 low, plus a build bug
fast_uuid	0.8.1	5: 4 low, 1 by-design behaviour changed anyway
phonetic	0.4.4	3: 1 medium, 2 low
nameparser	1.6.0	5: 1 medium, 1 low, 3 informational

A few findings in upstream libraries are reported privately to their maintainers and aren't described here until fixes ship.

The coordinating model was Mythos 5.1, but most of the work ran on other models: on fastjson, 695 of the 702 assistant messages came from Opus 5.5 subagents doing the reading, fuzzing, and PoC writing. The phpser scan doubled as an A/B/C test of my own tooling against a bare prompt, which I wrote up on X at the time. So the table measures the process more than any one model.

fast_uuid and phonetic came back with zero memory-safety bugs, and php_excel's wrapper with nothing above low severity.

Bugs that needed no attacker

The worst php_clickhouse finding in practice wasn't the high-severity one. It was B-4, which corrupted data on ordinary queries. Decimal and DateTime64 decoding cached each column's scale in a memo keyed on the raw address of the column's type object. clickhouse-cpp allocates a fresh type object per column per block and frees the block after each callback, so the next block's first column could land at the same address and inherit the previous column's scale. Select a scale-2 column next to a scale-6 one with max_block_size=100, and a stored 12.34 came back as 0.001234, with no error. With default settings the verifier still saw 1 wrong cell in 70,000 rows.

The test suite never caught it because ASan builds hide it: the sanitizer's quarantine stops freed memory from being reused, so the address never repeats. It took a release build and a real server. 0.13.0 keys the memo correctly.

0.13.0 also fixes a behaviour you should check for before upgrading. A whole-number insert into a Decimal column, 7 into Decimal(9,2), now stores 7.00 as the server does; 0.12 stored 0.07. Code that compensated by passing pre-scaled integers (700 meaning 7.00) will now store 700.00 without complaint.

fast_uuid's main finding has the same character. uuid1() and uuid6() with a fixed node and clock sequence kept no last-tick state, so uuid1(1, 7) called 500,000 times produced 61,723 duplicates. The default arguments were fine. 0.8.1 fixes it.

Bugs a server, a file, or a document could trigger

php_clickhouse's high-severity finding was a heap overflow write. With compression enabled, a malicious or compromised server could send a compressed frame whose declared size was smaller than the 9-byte frame header, and the client wrote past its buffer with bytes the server chose. clickhouse-cpp had already fixed it on master in PR #566, but no clickhouse-cpp release contains the fix yet, and php_clickhouse's prebuilt binaries ship the library. 0.13.0 carries the patch. The same release rejects seven more server-triggered crash shapes, from FixedString(0) columns to Array offsets that run backwards, and stops a packet of a few dozen bytes from committing gigabytes of memory outside memory_limit. I sent the fixes upstream as 15 pull requests; three have merged so far and twelve are open.

fastchart's two medium findings were both resource bombs. A 44 KB SVG passed to svgTo*() reached 2,121,264 KiB of resident memory through data URIs and <use> references that slipped past the input gate, all of it outside memory_limit; a 30,000-deep <use> chain crashed the process. A 1 MB CgBI PNG with decoy dimensions decoded into a 16000 by 16000 buffer. 1.8.0 runs the gate on the parsed tree, bounds <use> depth and expansion, and caps decoded images at 4,096 pixels a side. Some heavy but legitimate SVG that used to render slowly now throws a ValueError instead, so test your largest inputs.

mdparser's high-severity finding was quadratic parsing: blank lines inside deeply nested lists took 1.7 seconds at 200 KB and 55 seconds at 1 MB. Seven of mdparser's thirteen findings had their root cause in md4c rather than in my code, and the fixes went upstream; md4c merged five of my pull requests for them on October 13. One remaining low-severity signed overflow is still waiting in md4c#374. 0.8.0 also changes generated heading IDs to start with user-content-, which closes a DOM-clobbering finding and breaks existing links to heading fragments when headingAnchors is on.

The other high and medium findings

pdo_duckdb's high finding was a use-after-free: an appender left open inside a reference cycle could outlive its PDO handle when gc_collect_cycles() or request shutdown freed the handle first. Two of the medium-range findings were the same shape. A memory_limit bailout at the wrong moment during column setup left uninitialised type pointers that were destroyed later; the PoC got the sanitizer to report a destructor running on 0x4141414141414141. 0.8.0 fixes all six.

phpser's high finding was that a nested SPL unserialize() ignored allowed_classes. Its legacy handler path ran outside the decoder's context, so a class allowlist set on the outer call never reached the inner one. 0.7.1 fixes it along with eighteen others, most of them bounds on work an untrusted payload could demand.

nameparser's quadratic case, from the top of this post, is fixed in 1.6.0. Its release notes say plainly that earlier notes describing hostile-input parsing as linear "did not hold for these shapes". phonetic's medium finding was a 14-byte input, bmpm("de akeaxhaeasz"), that caused an uncatchable fatal error. 0.4.4 turns budget overruns into a catchable ValueError and caps BMPM output at 256 times the input size, after a 1,560-byte input had produced 3.9 MB.

memory_limit stopped stopping things

PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12 shipped on October 21 with the fix for CVE-2026-109618, rated critical. Part of that fix changes what happens when an allocation crosses memory_limit. The engine used to bail out on the spot with a longjmp. Now it records the error, lets the allocation succeed, and raises the fatal at the next safe point in the VM.

For PHP code that's invisible. For an extension it isn't. A C loop that decodes a payload or builds rows never reaches a VM safe point, so it keeps allocating past memory_limit until it hits a hard limit, by default twice memory_limit below 1 GiB. At the hard limit the engine calls _exit(): no shutdown functions, no destructors, no session write, and php-fpm loses the worker instead of failing one request.

So every loop whose length comes from input has to notice the pending error and stop on its own. This is how phpser does it:

/* PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12 queue a memory_limit error instead of
 * bailing out; the allocation still succeeds until a hard limit (2x the soft
 * limit below 1G) that _exit()s the process. Loops that keep allocating must
 * stop on their own once the error is pending. */
#ifdef ZEND_HAS_OOM
# define PHPSER_HAS_OOM() ZEND_HAS_OOM()
#else
# define PHPSER_HAS_OOM() 0
#endif

A loop check cannot help when a single allocation is sized from a count the payload declares. Those go through the new fallible allocators instead (zend_hash_real_finit(..., true), safe_femalloc, fecalloc), which queue the error and return NULL rather than running into the hard limit. phpser 0.10.0 uses both. mdparser 0.8.1 and pdo_duckdb 0.9.0 do the same for their input-sized loops and presizes.

The re-release day

There is a catch. The October headers route smart_str growth through a new engine function, smart_str_ferealloc(), from inline header code. An extension compiled against 8.4.27 headers imports that symbol even if it never mentions it, and 8.4.26 doesn't export it. My release workflows built prebuilt binaries against the newest patch of each PHP minor, which had always been the safe choice.

On October 26 that meant mdparser 0.8.1, phpser 0.10.0, fastjson 0.10.1, php_clickhouse 0.13.1, and phonetic 0.4.5 all shipped Linux and macOS binaries that died with undefined symbol: smart_str_ferealloc on every PHP 8.4 before 8.4.27 and every 8.5 before 8.5.12. Source builds were fine, because they compile against the PHP they load into. All five were re-released the same day as mdparser 0.8.2, phpser 0.10.1, fastjson 0.10.2, php_clickhouse 0.13.2, and phonetic 0.4.6, and fastchart 1.8.1 picked up the same change before it could break. Their prebuilts now compile against the oldest patch of each minor (8.4.1, since 8.4.0 was never released, and 8.5.0), and each binary has to load on both the oldest and the newest patch before anything uploads.

That fix has a cost, and the phpser changelog states it: a binary built against 8.4.1 headers doesn't have the memory_limit stop. To get it, you build from source on a patched PHP.

Refusing vulnerable PHP releases

The longer-term answer is the opposite trade. pdo_duckdb 0.9.0 makes it today: its prebuilt binaries are built against the patched headers and require PHP 8.2.35, 8.3.36, 8.4.27, or 8.5.12 or newer. Load one on 8.4.26 and the process stops at the first call:

php: symbol lookup error: /ext/pdo_duckdb.so: undefined symbol: smart_str_ferealloc

That message is honest but unfriendly, and it arrives at runtime rather than at startup. The next releases of pdo_duckdb, phpser, and mdparser fix that with a startup check. On PHP 8.3 and newer, the module compares the running patch with the one it was compiled against and refuses to start on an older one, naming both versions. This is mdparser's:

if (php_version_id() < PHP_VERSION_ID) {
    zend_error(E_CORE_WARNING,
        "mdparser was built for PHP %s and cannot run on PHP %s; "
        "install a build for this PHP version or build from source",
        PHP_VERSION, php_version());
    return FAILURE;
}

With that check in place, pdo_duckdb keeps the binaries it already builds against the patched headers, and phpser and mdparser can move theirs back to the patched headers and regain the memory_limit stop. A server still on 8.4.26 gets a clear startup warning instead of a crash on the first request, and with a critical CVE fixed in 8.4.27 it should move anyway.

pdo_duckdb 0.9.0: DuckDB 2.0

DuckDB 2.0.0 went GA on October 21, and pdo_duckdb 0.9.0, out today, bundles it in every prebuilt binary. 0.8.0 had already built against the 2.0 previews. Source builds still work against DuckDB 1.5.3 and newer; configure detects 2.0 from duckdb_v2.h, because the 2.0 headers still report C API version 1.5.6, and it refuses to build when 2.0 headers meet an older libduckdb.

The upgrade is not transparent, and the README has a full section on it. The one most likely to bite is the file format. DuckDB 2.0 writes new files at storage version 69, and DuckDB 1.5 reads only 64 to 68. If a 1.5 process has to read the file too, ask for the older format when you open it:

$db = new PDO('duckdb:/data/shared.duckdb;storage_compatibility_version=v1.5.6');

On the 0.9.0 binary, a file opened that way reports v1.5.0+ in duckdb_databases(), and a default one reports v2.0.0+. Existing 1.5 files keep their format after 2.0 writes to them. The rest is DuckDB's own behaviour: a failed statement now invalidates the whole transaction, integer division by zero throws, single-arrow lambdas are rejected, and the new PEG parser is the default. That last one has a sharp edge for parameter binding: $1_0 means parameter 10 under PEG and parameter 1 under the legacy parser. Each change has a setting that restores 1.5 behaviour.

0.9.0 also adds PDO::DUCKDB_ATTR_NATIVE_STRUCTURES, an opt-in that fetches LIST, ARRAY, STRUCT, TUPLE, MAP, UNION, JSON, and VARIANT values as lossless PHP structures instead of canonical strings, with exact numerics, binary keys, and SQL NULL kept distinct from VARIANT null. VARIANT works top-level and nested, and the appender accepts PHP arrays and objects for it.

One fix in 0.9.0 matters even if you never touch 2.0: two PDO connections to the same database file could lose writes and see stale reads. Equivalent paths now share one DuckDB instance while transactions stay connection-local.

Performance, with the hardware attached

Most of the speed work came before the scans. Apart from the nameparser row, which I re-ran for this post, these are the numbers from each project's changelog with the conditions it states.

Project	Change	Measured on
nameparser 1.6.0	16 KB hostile row: 17.4 s to 0.064 s	i9-13950HX, PHP 8.4.27 (my rerun of 1.5.0 vs 1.7.0)
phpser 0.6.0	`range(0, 9999)` encodes to 7 bytes; encode 57% faster, decode 66% faster	aarch64
phpser 0.7.0	Signed decode 53 to 85% faster; 1,000-row rowset decodes in 429 KB instead of 645 KB	aarch64
fastjson 0.9.0	`fastjson_validate()` costs 0.47 to 0.90x a full parse, down from 1.1 to 1.9x	Neoverse-N1
fastjson 0.9.0 to 0.10.0	Key-heavy decode peak memory about 15% lower; file decode peak 9 to 33% lower	Neoverse-N1
fast_uuid 0.8.0	`uuid_v4()` 76 to 42 ns; `uuid_v4_bin_batch(100)` 61 to 27 ns per UUID; `uuid_v7_bin_batch()` 25.9 to 16.6 ns	Neoverse-N1
mdparser 0.6.2	`toAst()` 5 to 9% faster; retained AST memory 47% lower on softbreak-dense input; code-heavy `toXml()` output 49% smaller in memory	aarch64, PHP 8.4.25
php_clickhouse 0.12.0	Temporal, string, and IP inserts about 19% faster; IPv4 selects about 12%	200,000-row probes

The phpser integer-run encoding is the one I'd point at. A run with a constant step is stored as a start, a step, and a count, so range(0, 9999) encodes to 7 bytes and range(0, 999999) to 8. Native serialize() needs 137,790 bytes for the first one.

fast_uuid's speedup comes from refilling its random buffer with a userspace AES-256-CTR generator with fast key erasure, instead of a getrandom() call per 8 KiB, on CPUs with AES instructions. It has one caveat, and the changelog states it: clones of one VM snapshot can repeat up to 64 KiB of output per thread.

Breaking changes worth reading before you upgrade

Most of these releases are drop-in. These are not:

php_clickhouse 0.13.0: whole-number Decimal inserts scale like the server's (above).
mdparser 0.8.0: heading IDs carry a user-content- prefix.
phpser 0.10.0: Closures and other unserializable objects throw instead of quietly encoding NULL. Check what you put in $_SESSION before upgrading. New wire tags since 0.7.0 mean readers must upgrade before writers.
php_excel 2.9.0 and 2.9.1: dates use PHP's timezone rather than the OS one, and text is UTF-8 regardless of the process locale. Apps that relied on the locale to pass non-UTF-8 bytes through will see different output. 2.7.0 also rejects a font from a different ExcelBook in addText().
fastchart 1.8.0: heavy SVG that used to render slowly may now throw ValueError.
phonetic 0.4.4: oversized BMPM and Daitch-Mokotoff work throws a catchable ValueError rather than ending the request.
statgrab 2.2.2: Statgrab::ERROR_UNSUPPORTED is 44, matching libstatgrab; it was 41.

On the feature side, phpser 0.8.0 and 0.9.0 added signed sessions (phpser.session_key, HMAC-SHA256), an APCu serializer (apc.serializer=phpser), keyed payloads, and an exported C API. nameparser 1.4.0 understands joint salutations, so Mr. and Mrs. Brad Smith keeps Brad as the first name, with new isJoint(), getSalutations(), and getPartner(), and 1.4.1 raised first-and-last accuracy on 30,000 NPPES provider rows from 95.94% to 97.18%. statgrab 2.3.1 fixes a heap overflow in the bundled libstatgrab's Linux command-line handling that the scan didn't cover.

What a scan is worth

None of these projects were neglected before October. Each had a test suite and documentation that said where its limits were. The scans still found an allowlist that didn't reach a nested call, a Decimal that came back ten thousand times too small, and a 16 KB name that took 17 seconds. Two of the most consequential findings sat in code I had already called linear or already tested under ASan, and for the Decimal bug the ASan testing is exactly what hid it.

The fixes are released and listed above. Upgrade pdo_duckdb if you are moving to DuckDB 2.0, php_clickhouse if you talk to a server you don't control, and PHP itself to 8.4.27 or 8.5.12 whatever else you do.

What SafeLine's PHP Core Rule Actually Watches in the Request

Mon, 26 Oct 2026 04:17:15 +0000

The PHP Core rule SafeLine shipped on 21 October is not a generic "block all uploads" switch. It is aimed at request features from the known chain behind CVE-2026-109618 and CVE-2026-109619.

Four signs are called out in the rule note. A request that carries PHP_SESSION_UPLOAD_PROGRESS. A PHPSESSID that fits the characteristic pattern. A content type of multipart/form-data. A body that combines abnormal form fields with suspicious content. Any one of those can appear in legitimate software. The rule is about the combination associated with the chain, which is why the first setting is observe, not drop.

That focus follows from CVE-2026-109618, which is about multipart parsing and memory state. Upload and form posts are the traffic you should be able to name in a log: time, source address, site, path, and the rule name PHPCoreRCECVE-2026-109618/109619. The write-up is at the rule discussion.

CVE-2026-109619 is the other half. Worker global state can linger between requests. The WAF rule will not print the worker's memory. It will tell you which HTTP client was sending the chain's request shape at the time a pool misbehaved. Use both logs.

Import the rule from the SafeLine rule library. Set the action to blacklist. Enable observe mode. Review a sample of hits against a known-good upload from your own application. If your application itself sends PHP_SESSION_UPLOAD_PROGRESS on a normal photo upload, you need that fact before you block, not after.

When the hits are probes rather than product traffic, move the rule to an intercept action and keep the event record for the follow-up on disk and credentials.

Does the rule fire on every multipart post?

It is built around the known chain's features, not every form on the internet.

What should a useful hit contain?

Time, source IP, site, path, and the rule name. Those are the fields worth capturing in the event view.

Can I skip observe mode if I trust the signature?

You can, but the published guidance is to observe first so a real upload path is not the thing you discover by outage.

SafeLine has surpassed 700,000 installations worldwide as of September 30, 2026. SafeLine Pro annual promotional pricing is $650-$880, compared with the regular $1,000 per year.

SafeLine website: https://ly.cyberserval.tech/MqhYdmI
Demo: https://demo.waf.chaitin.com:9443/statistics
Official docs: https://docs.waf.chaitin.com/en/home
GitHub: https://github.com/chaitin/SafeLine
Pro offer: https://cyberserval.tech/landing/lto

What to Inspect After a PHP Core Rule Hit

Mon, 26 Oct 2026 04:17:14 +0000

A SafeLine hit on the PHP Core rule is a starting point, not a closed case. CVE-2026-109618 and CVE-2026-109619 are serious because a crafted request can disturb the runtime or leave worker state behind. If the rule fires, or if the server looks wrong without a clean explanation, widen the search the same day.

Start with the event SafeLine already stored: attack time, source address, site, path, and the rule name. The 21 October rule is documented at the rule page. Match that minute to the web access log and the PHP error log. You are looking for the same client, the same path, and a runtime fault.

Then look at files. Check the web root, the upload directory, and the temporary directory PHP uses for multipart bodies. Look for PHP files that appeared or changed recently and that no deploy can explain. A new file next to an upload endpoint is more interesting than a hit with no file change, but both deserve a note.

Process and network checks come next. Unknown processes, unexpected outbound connections, and cron entries you did not add are reasons to treat the host as suspect. If that bar is met, rotate high-privilege accounts, database accounts, and API keys. Do not rotate everything on the first observe-mode hit from a scanner. Do rotate when logs and files agree that something landed.

Keep the rule in observe until you know your own upload traffic, then move it to block. Upgrade the PHP pool that served the hit. Restart that pool. Confirm the site still logs in and still accepts a normal file. The rule watches the chain. The upgrade removes the bug the chain is aimed at.

What is the minimum record to keep?

Time, source IP, site, path, rule name, and whether a file changed.

Should every hit trigger a credential rotation?

No. Rotate when logs or files show more than a probe.

Does blocking replace the PHP upgrade?

No. Blocking is a control at the proxy. The runtime still has to be patched.

SafeLine has surpassed 700,000 installations worldwide as of September 30, 2026. SafeLine Pro annual promotional pricing is $650-$880, compared with the regular $1,000 per year.

SafeLine website: https://ly.cyberserval.tech/MqhYdmI
Demo: https://demo.waf.chaitin.com:9443/statistics
Official docs: https://docs.waf.chaitin.com/en/home
GitHub: https://github.com/chaitin/SafeLine
Pro offer: https://cyberserval.tech/landing/lto

How to Inventory Every PHP Version Before You Call the Estate Patched

Mon, 26 Oct 2026 03:47:14 +0000

The failure mode in this PHP advisory is not "we upgraded PHP." It is "we upgraded one PHP and left three others running." CVE-2026-109618 and CVE-2026-109619 are in PHP Core, so every branch on the host is its own decision.

Build a table before you patch. Columns that earn their keep: site name, public host, PHP-FPM pool, binary path, version, owner, and status. Status should be one of upgraded, waiting, or cannot upgrade, with a reason in the last case. A shared server that still has an old pool for a forgotten landing page is still exposed.

Do the upgrade in a quiet window. Back up site files, the database, and the pool config first. After the package change, restart PHP or PHP-FPM and prove the new version with the same binary the pool uses, not with a php that happens to be first on a login shell.

Then test the paths that exercise the bugs: home page, login, upload, and a normal form post. Read the PHP error log for a new exception. Walk the process list and confirm no pool is still bound to the old build.

SafeLine does not replace that inventory. The 21 October rule gives you a place to watch suspicious multipart uploads while the list is incomplete. Set the action to blacklist, enable observe mode, and read hits instead of blocking the estate on hour one. The rule page is here.

When the inventory shows a site that cannot move yet, keep that host's rule in observe, restrict who can reach the origin, and do not treat the WAF note as a permanent patch.

How do I know which version a vhost uses?

Read the pool config and the binary that pool executes, not the default CLI PHP.

Can one SafeLine rule cover every old branch?

It can watch the request pattern. It does not upgrade the branch.

What belongs in the "cannot upgrade" note?

The business reason and the compensating control, such as observe mode plus a closed origin.

SafeLine has surpassed 700,000 installations worldwide as of September 30, 2026. SafeLine Pro annual promotional pricing is $650-$880, compared with the regular $1,000 per year.

SafeLine website: https://ly.cyberserval.tech/MqhYdmI
Demo: https://demo.waf.chaitin.com:9443/statistics
Official docs: https://docs.waf.chaitin.com/en/home
GitHub: https://github.com/chaitin/SafeLine
Pro offer: https://cyberserval.tech/landing/lto

Why Multipart Uploads Need a Separate Look After CVE-2026-109618

Mon, 26 Oct 2026 03:44:13 +0000

File upload is the practical entry for CVE-2026-109618. The weakness is in PHP's handling of multipart/form-data and the memory state around that parse, not in a single shopping-cart plugin.

An attacker does not need a valid image. They need a request that looks like a form upload and stresses the parser: odd boundaries, unexpected fields, or a progress token the application never meant to honor. The result called out in the advisory is service disruption or a runtime fault, which is enough to create a window for a follow-on web attack.

SafeLine's 21 October rule looks for that shape on the wire. The signals called out in the rule note are a PHP_SESSION_UPLOAD_PROGRESS parameter, a PHPSESSID that matches the known pattern, a multipart/form-data content type, and a body that pairs abnormal fields with suspicious content. Details are in the rule discussion.

Turn the rule action to blacklist and leave observe mode on. Observe mode writes the event and keeps the source and request. It does not drop the request. That matters on checkout, profile photo, and ticket-attachment routes, where a hard block on day one will page the wrong team.

While the rule watches, do the origin work. Back up files, the database, and the PHP pool config. Upgrade the PHP branch that pool actually uses. Restart PHP-FPM. Then click through home, login, upload, and form submit. Read the PHP error log for a new fault, and confirm no second vhost is still pinned to the old binary.

If the same address keeps changing the body of upload posts, treat that as probing even when the rule is still in observe. Only after that picture is stable should you switch the rule from record-only to block.

Is every upload form affected?

Any PHP path that accepts multipart bodies is in scope until that site's runtime is confirmed current.

Will observe mode stop the exploit?

No. It records. Blocking is a later, separate change.

What should be upgraded first?

The PHP version serving the upload vhost, not the CMS theme.

SafeLine has surpassed 700,000 installations worldwide as of September 30, 2026. SafeLine Pro annual promotional pricing is $650-$880, compared with the regular $1,000 per year.

SafeLine website: https://ly.cyberserval.tech/MqhYdmI
Demo: https://demo.waf.chaitin.com:9443/statistics
Official docs: https://docs.waf.chaitin.com/en/home
GitHub: https://github.com/chaitin/SafeLine
Pro offer: https://cyberserval.tech/landing/lto

Finding the slow part of a WooCommerce page with Query Monitor

Sat, 24 Oct 2026 22:32:40 +0000

Query Monitor is a free WordPress plugin by John Blackbourn. It adds a panel to the admin toolbar that shows what one page load did: database queries, hooks, HTTP calls, PHP errors and the template that rendered the page. On a WooCommerce store it answers the usual question, "which plugin makes the product page slow", with numbers instead of guesses.

Install it on staging first

Query Monitor shows its panel to administrators only, so customers on a live store never see it. It still does its work on every request you make while logged in, which is why staging is the better home for it. Install it from the plugin directory and activate it. The toolbar then shows four figures for the current page: generation time, peak memory, database query time and the number of queries.

Read the queries by component

Open the panel and go to Queries by Component. Every query is attributed to the plugin, theme or core file that made it, with a count and a total time. Sorting by time usually points at one or two plugins.

Duplicate Queries is the next view to open. The same query repeated dozens of times in one request often comes from a loop that reads product meta one product at a time.

Slow Queries lists every query that took longer than 0.05 seconds. That threshold is the QM_DB_EXPENSIVE constant, and you can lower it in wp-config.php when the whole page is slow but no single query stands out.

Check outgoing HTTP calls

The HTTP API Calls panel lists the requests a page sent to other servers while it was being built. Licence checks, currency rates and shipping quotes are the usual suspects. A plugin that calls an external API on every product page adds that server's response time to yours. For each call the panel shows the URL, the response code and how long it took.

Time your own code

Query Monitor also has a small profiling API. Wrap a block of code in two actions and it shows up in the Timings panel:

do_action( 'qm/start', 'shipping_estimates' );
// the code you want to measure
do_action( 'qm/stop', 'shipping_estimates' );

For a value you want to inspect, do_action( 'qm/debug', $variable ); sends it to the Logs panel instead of the page output.

Look at a page as a guest

Some slowness only appears for logged-out visitors, for example when a cache plugin treats them differently. The Query Monitor settings can set an authentication cookie, and with it the panel keeps working in the same browser after you log out.

When you are done

Deactivate the plugin once the slow part is found. It is light, but there is no reason to keep it running on a store that nobody is debugging.

You patched PHP. The old image is still in your cluster’s future.

Fri, 23 Oct 2026 17:56:15 +0000

title: "You patched PHP. The old image is still in your cluster's future."
published: false
description: "PHP2Shell (CVE-2026-109618, CVE-2026-109619) as seen from a Kubernetes cluster: how fast the scanners caught up, where they stay blind, and why rebuilding the image is only half of remediation."

tags: kubernetes, security, php, devops

On 21 October PHP shipped fixes for two critical bugs in the engine itself, CVE-2026-109618 and CVE-2026-109619, both CVSS 9.2, both reachable without authentication, both already being exploited by the time most people read the advisory. The community name is PHP2Shell. Fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. CISA and the UK NCSC both published "patch now" notices the same day.

I am not going to explain the bugs; Wiz, watchTowr and Qualys have done that well. I want to write about what happened in Kubernetes teams in the forty-eight hours after, because I watched it happen and because the second half of it is the part nobody schedules.

How most teams found out

From the news. Then someone opened a spreadsheet and typed "PHP" into the first column.

This is not a criticism. It is what a platform team does when the only inventory of what runs in production is the memory of the people who deployed it. The questions that followed were always the same three:

Which clusters run PHP at all?
Which images, which versions?
Who gets to say "we are done"?

The third question is the one that comes back in March, when an auditor asks what you knew on 22 October and what you did about it.

How fast the scanners caught up

I measured this on 23 October, two days after the advisory, with Trivy 0.72.0 and whatever vulnerability database it pulled that afternoon. You can repeat every step.

The database build was stamped 13:13 UTC on 23 October. Both CVEs were in it, with the Debian and Alpine advisories attached:

$ grep -a -o CVE-2026-109618 ~/.cache/trivy/db/trivy.db | wc -l
1247
$ grep -a -o CVE-2026-109619 ~/.cache/trivy/db/trivy.db | wc -l
1253

Debian's security tracker already listed php8.2 as resolved in 8.2.35-1~deb12u1 for bookworm and php8.4 in 8.4.27-1~deb13u1 for trixie. Alpine's secdb for 3.22 carried both CVEs. A debian:bookworm-slim image with php8.2-cli installed from the archive that day came out as 8.2.35, already fixed; a alpine:3.22 image with php84 came out as 8.4.27, also fixed.

So the honest answer to "did the open-source scanners keep up" is yes, within two days, for PHP installed as a distribution package. That is good news and it is the ordinary case for a lot of internal images.

Now the uncomfortable part.

$ trivy image --scanners vuln --severity CRITICAL,HIGH php:8.3-fpm

126 CRITICAL and HIGH findings. Not one of them about PHP.

The official php:* images build PHP from source. There is no php8.3 package in the image for a package scanner to look at, so Trivy, and every scanner that works from the package database, has nothing to match the advisory against. The 126 findings are the Debian base. The thing you actually care about is invisible.

This is not a Trivy bug. It is what package-based scanning is. But it means that if your PHP workloads run on the official image, or on any image that compiles PHP, then a quiet scanner is not a clean bill. It is silence.

What you can do about it this week, in order of effort:

Ask the binary. docker run --rm <your-image> php -v tells you the truth in one line. Do it for every PHP image tag you run, not the ones you think you run.
Rebuild on a base that was pushed after 21 October, pin the digest, and write the digest down somewhere an auditor can read.
If you can, move to distribution packages for the runtime. It costs you a newer PHP, it buys you a scanner that can see it.

Patching is half the job

Here is the part that gets skipped. You rebuild the image, you roll the Deployment, the pods come up on 8.3.36, everyone exhales.

The old image did not go anywhere. It is still in the registry. It is still in helm history. It is the image someone will roll back to at 03:00 when the new build has a problem that has nothing to do with PHP. It is in the CI cache, in the staging cluster nobody looks at, in the Job that runs once a month.

Remediation has two halves:

Run the fixed image.
Make it impossible for the vulnerable image to run again, and keep a record that proves both.

Most teams do the first half and call it done. The second half is what an admission controller is for.

What this looks like with an admission controller in the path

This is where I talk about what we built, so take the next paragraphs for what they are. Attestkeep is an admission controller for Kubernetes that scans, verifies signatures, decides at admission, and keeps the record. Here is exactly what it did, and did not do, for PHP2Shell.

The database refreshes itself. The scanner pulls a fresh vulnerability database every six hours. Trivy publishes one every six hours too, so the lag between an advisory landing upstream and the cluster knowing about it is measured in hours, not in someone's calendar.

Every admitted image is rescanned. Once a day by default (scan.rescanInterval in the chart, if you want it shorter), every image the cluster has ever admitted is scanned again against the current database. An image that was clean on Monday and carries a CVE on Thursday shows up as not compliant on Thursday, with the CVE named. You do not open a spreadsheet; the inventory is the admission ledger.

It tells you. A scan that finds critical vulnerabilities raises a critical_finding event, which goes to whichever channel you configured: email, Slack, Teams, a webhook, Jira, GitLab. When a running image flips from "would be admitted" to "would be denied", that is a second, separate message: "Running image now fails policy". That is the message an operator actually needs.

New pods with the image are refused. If your policy blocks critical findings, the vulnerable image cannot be admitted again. The rollback at 03:00 fails with a reason, the Job that runs monthly fails with a reason, the staging cluster with the same policy refuses it too. The old image is still in the registry. It is no longer in your cluster's future.

Running pods are not killed. This is deliberate. Attestkeep does not evict a workload because a database update changed its verdict; that is an operator's decision, with the blast radius in front of them. What it does is make sure the next decision, any next decision, goes the right way, and that the running population is reconciled against the ledger on a schedule so drift is visible.

If the exploit lands first, there is a second line. PHP2Shell ends in a shell. If Falco is connected, a shell spawned inside a container is a runtime event, and a runtime policy can turn that event into a notification, an issue, or stopping the pod. That is not prevention, it is containment, and it is worth having when the window between advisory and rebuild is days.

Every decision is signed. The admission ledger records the image digest, the policy revision that ran, the verdict and the reason. When the auditor asks in March what you knew on 22 October, the answer is a record with a signature, not a recollection.

And the blind spot above applies to us exactly as it applies to Trivy, because Trivy is the scanner inside. If you run the official php:* image, Attestkeep's rescan will not name CVE-2026-109618 either. It will show you the digest you admitted, when, and under which policy. The php -v step is still yours. I would rather tell you that here than have you find it out from a pentest report.

The checklist, tool-agnostic

For this week, whatever you run:

List every image whose name or Dockerfile mentions PHP. Not from memory; from the cluster.
For each, run php -v inside the image. Trust that over the scanner.
Rebuild on a post-21-October base, pin digests.
Add a rule that refuses the old digests at admission, so a rollback cannot resurrect them.
Write down what you found, what you changed, and when, in a form that survives until the audit.

If step 4 is a policy in an admission controller and step 5 is produced automatically, this is a Tuesday. If step 4 is a Slack message and step 5 is a Confluence page, it is a project, and it will be a project again at the next CVE.

Closing

The lesson of PHP2Shell for platform teams is not "patch faster". Everyone patched. The lesson is that the news is a bad way to learn what is in your cluster, and that a patched Deployment with the old image still admissible is not a remediated cluster.

Let the cluster do the checking. Keep the record. Make the old image a thing that cannot come back.

Sources: CISA alert, 21 October 2026 · NCSC advisory · watchTowr FAQ · Qualys · Google Cloud response. Scanner measurements are mine, 23 October 2026, Trivy 0.72.0; the commands are in the text.

Attestkeep runs inside the cluster it protects; every security feature is in the free edition. attestkeep.com · docs.attestkeep.com

PHP2Shell: Two 9.2-Rated Flaws Reach Back to PHP 5. Here's the Plan for EOL Teams

Thu, 22 Oct 2026 13:00:00 +0000

PHP shipped emergency patches on October 21 for two critical flaws now known as PHP2Shell. Both are rated 9.2 under CVSS v4.0. Both can let an unauthenticated attacker run code on your server.

The fixes are in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If you run a supported branch, update and restart your PHP workers. That part is simple.

The harder question is what to do if you run a version that no longer gets community patches. A lot of teams are in that spot.

I asked Matthew Weier O'Phinney about it. He's principal product manager for Perforce OpenLogic and Zend, and he sits on the PHP Foundation board. Perforce sells extended support for end-of-life (EOL) open source software, so keep that in mind when he talks about extended support. But he also had a close view of how this disclosure played out.

What the flaws do

CVE-2026-109618 corrupts memory when PHP hits an out-of-memory error in the middle of a request. CVE-2026-109619 involves stale global state. PHP keeps pointers to request data after that memory has been freed.

Weier O'Phinney put it in plain terms. "An attacker can create one or more payloads that simulate large file uploads, or multi-file uploads, that hit configured memory limits for the PHP application," he said. Because of how PHP handled memory and errors at that moment, the attacker could end up running system commands on the server.

The attack doesn't need a vulnerable application or a public upload form. And the timeline was tight. Details leaked on October 20, a day before the coordinated release. Security firm Sansec reports that Cloudflare saw attacks hours before the patches shipped.

It's not just mod_php

PHP's advisory named Apache's mod_php as the highest-risk configuration. Some early coverage stopped there. Weier O'Phinney says that's too narrow.

"These vulnerabilities affect every single Server API (SAPI) provided by the language, because their roots are deep within how the engine manages memory and handles errors," he said. "If you run PHP, your application is affected, plain and simple."

mod_php may be the easiest path in. But PHP has also confirmed remote code execution against PHP-FPM under the right application conditions. If you run FPM behind Nginx, you're not off the hook.

Workarounds buy time. They don't fix the problem.

The early advice was to turn off session upload progress and remove memory limits. Weier O'Phinney says those steps help, but only so much. "They just change the size of the file upload payloads the attacker needs to use to exploit the system," he said.

He's more positive about two other measures:

A web application firewall (WAF) that limits which paths accept uploads, or any user submission
AppArmor or SELinux to restrict PHP's access to system binaries

Both are good defense-in-depth. But he warns that creative attackers can still find ways around them if the PHP runtime underneath is vulnerable.

PHP says the same thing. Updating is the only complete fix. If you removed the memory limit as a stopgap, put a container or cgroup limit in place, and restore a finite limit once you've patched.

The end-of-life problem

Here's where it gets uncomfortable. According to Weier O'Phinney, every PHP version before 8.2 is past community support. And 8.2 reaches end of life at the end of this year.

These flaws trace back to the PHP 5 series. "If you're running PHP 5, PHP 7, or early PHP 8 versions, you will need to audit your applications and deployments," he said.

He sees two paths:

Use a commercial long-term support (LTS) provider. Several have patched EOL versions. Perforce Zend patched PHP 7.2, 7.3, 7.4 and 8.1 in coordination with the PHP Security team. If you already have a provider, confirm it shipped patches for your version.
Start migrating to a community-supported version. That means 8.2 or later. Since 8.2 is nearly at end of life itself, a migration that stops there only buys you a couple of months.

If you have neither, his advice is to pick one today.

AI changed the clock

The backstory matters here. A security audit sponsored by the Sovereign Tech Agency and the PHP Foundation found these attack vectors last year. But the security team couldn't find a practical way to trigger them. They treated the flaws as largely theoretical and kept working on them off and on.

Then, this past August, two independent researchers found the same issues within days of each other. Each was using a frontier AI model. Each built a way to exploit them. The PHP Security team had to move them to the top of the list.

That's the real shift. A bug that sat in the "theoretical" pile for a year became practical in a matter of days.

Weier O'Phinney sees the same pattern across open source. The cURL project has been handling a flood of AI-discovered reports for two years. Spring has seen a big jump in reports this year. And those reports still need people to review them. Maintainers have to confirm that each patch works, doesn't break existing behavior and doesn't add new flaws. Many AI-generated reports also overstate severity, which takes more time to sort out.

For EOL software, this is the core risk. Discovery is speeding up. Patches for unsupported versions aren't.

Migration or extended support?

Weier O'Phinney is clear that migration is the goal. Current versions get new features and security fixes first, and the rest of the ecosystem tends to follow the latest releases.

But he's also realistic. Continuous upgrades take discipline, solid testing and QA, and a DevOps team that can roll releases out and roll them back. Some companies also face regulatory reviews every time they move to a new feature release. That costs time and money, so migration gets pushed back.

"So adopt those new versions if you can, but have a plan for when you cannot," he said.

That's fair advice, and it's worth taking at face value. Extended support is a bridge, not a destination. If you're evaluating a provider, ask one simple question: how fast did it ship PHP2Shell patches for your version? The answer tells you a lot.

How the disclosure worked

Weier O'Phinney knew for a couple of months that big security patches were coming. He didn't know the details. "That's a good thing," he said. Fewer people in the loop means less chance of a leak.

The PHP Foundation now employs a small team that coordinates security work between researchers and the PHP project. One of them contacted Weier O'Phinney in his role at a commercial LTS provider to line up releases. In more than 20 years at Zend, that was a first for him. The PHP Security team worked with Zend's packaging team and reviewed its patches so both were ready on release day.

His bigger concern is capacity. The PHP Security team is small, and the volume of incoming reports keeps growing. He'd like to see it staffed well enough to coordinate like this more often. His ask: if your company depends on PHP, consider donating to the PHP Foundation.

What to do this week

Find every PHP runtime you have. Check servers, containers, base images and hosting accounts. Trust php -v, not your documentation.
Patch supported branches now. Move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, then restart PHP workers so the new code is actually running.
Check EOL versions separately. If you use an LTS provider, confirm it has shipped fixes. If you don't, choose between getting one and starting a migration.
Treat workarounds as temporary. Undo emergency config changes once you've patched.
Keep the extra layers. A WAF and AppArmor or SELinux are worth having after the patch, too.
Plan for more of this. AI-assisted discovery isn't slowing down. Budget time for triage and upgrades, not just for incidents.

PHP2Shell will get patched on most supported systems this week. The teams still exposed next month will be the ones running PHP that nobody owns. Now is a good time to find out if that's you.

A Clean Scan Is a Data Point, Not a Verdict: Lessons from PHP2Shell Week

Thu, 22 Oct 2026 05:13:41 +0000

PHP's two critical flaws, CVE-2026-109618 and CVE-2026-109619 (PHP2Shell), were patched in 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The advice everywhere was to update. I want to write about something less covered: how much you can honestly claim afterwards.

The scan that found nothing

I ran Laravel Scalpel, an open source filesystem intrusion scanner, against three Laravel applications after updating. No backdoor files. My first instinct was relief. My second was to ask what that result actually rules out.

Why a negative result is weak evidence

A scan can only report on what it can see, and it can only recognise what it knows how to recognise. Scalpel looks at five things: PHP files in places they should not be, known obfuscation patterns, risky directives in .htaccess and .user.ini, the integrity of .env, and differences from a saved baseline. Each is a question it answers well. Anything outside them is a question it never asks. Coverage and sensitivity multiply, and if either is low, 'found nothing' tells you little.

There are at least two explanations for my result. My applications are small, which lowers the odds that anything needed to hide. Or something sits outside the questions above. A scanner inside the application also shares the web server's user, so a flaw that grants code execution in that process gives an attacker the means to tamper with the tool. I ran Scalpel from inside the application and through an external runner for that reason, which narrows the gap without closing it. My strongest evidence is not the scan but a routine that predates it: since April, a scheduled external diff against my baseline has reported to a Telegram bot. I refreshed the baseline myself after the update, so any unexpected change before that should already have alerted me, and none did. That evidence has conditions too: the runs must actually have happened in the window, and the alert level must cover what an attacker would change. Scalpel's documentation states the first limit plainly, and I would rather state all of them than have a reader discover them. From the output alone I cannot separate these cases.

A ladder of claims

It helped me to treat each check as supporting a different, specific statement:

Version verified: the PHP that serves web traffic is a fixed version, containers included. Supports: 'this flaw can no longer be used against us.'
Logs reviewed from 20 October: no repeated 500s or memory limit errors that look like probing. Supports: 'we saw no sign of attempts in these logs.'
Filesystem scan clean: no known backdoor patterns in the application files. Supports: 'we found no evidence of intrusion in these files.'
Secrets rotated: exposed credentials no longer work. Supports: 'even if memory was read, those secrets are dead.'
Rebuilt from a known good image: supports the only claim close to 'clean.'

Most of us stop at rungs one to three and announce we are fine. Only the last rung justifies that word.

Why the timing makes this sharper

The identifiers leaked about a day before the fix, and a security firm reported exploitation attempts shortly after release. For teams that patched hours or days later, the unprotected window was real, and a patch does nothing about what happened inside it.

What I would write in a post-patch note

Something like: 'Updated PHP on this date. Reviewed logs from 20 October. Scanned the application filesystem. Found no evidence of intrusion in those places. Rotated these secrets.' Each sentence is a claim you can defend, and the places you did not check are visible by omission.

I would be glad to hear what steps other teams include in their own post-patch verification.

php2shell: how are you confirming which PHP your web traffic actually runs on?

Thu, 22 Oct 2026 01:34:44 +0000

PHP's 21 October fixes (8.5.12 / 8.4.27 / 8.3.36 / 8.2.35) cover two critical runtime flaws. Because they sit below the application, updating a CMS or framework doesn't help — the runtime has to change and workers have to restart.

The step I'd expect to trip teams up is inventory. php -v on a shell tells you about the CLI, not necessarily what PHP-FPM, mod_php or a bundled appliance is serving.

What are you using to answer "where does PHP run and is it patched?" — package queries, phpinfo() behind auth, image scanning, something else? And has anyone found a clean way to confirm old FPM workers are gone after the upgrade?

Write-up with versions, interim settings and detection signals: https://dev.to/_firelinks/php2shell-a-request-that-fails-halfway-still-leaves-state-behind-5877

Stripe Webhooks in Laravel: Verify, Dedupe and Retry Safely

Wed, 21 Oct 2026 00:02:45 +0000

If you take payments with Stripe, the money moving is only half the story. The other half arrives later as Stripe webhooks: messages that tell your app a payment succeeded, failed, was refunded or disputed. Handle them badly and you get customers who paid but have no access, double-processed orders, or a billing status that quietly drifts away from reality.

I build these integrations as part of API development and integrations work. This guide covers how to receive Stripe webhooks safely in Laravel: verifying them, ignoring duplicates, responding fast and recovering when something fails.

Why webhooks, not just the redirect after checkout

When a customer pays, Stripe sends them back to your site. It is tempting to mark the order paid at that moment. Don't rely on it. The customer can close the tab, lose connection or never reach your success page, and payments can also change state later (failed renewals, refunds, disputes).

Webhooks are the reliable channel. Your app should treat the webhook as the source of truth for payment state and the redirect only as a friendly "thanks" page.

The six rules for a safe webhook endpoint

1. Verify the signature

Anyone can send a request to your public URL. Stripe signs every event with a Stripe-Signature header, and you must verify it against your endpoint's signing secret before trusting the payload. Stripe's webhook documentation explains the scheme. Verification needs the raw request body, so read it before any middleware changes it.

use Stripe\Webhook;
use Stripe\Exception\SignatureVerificationException;

public function handle(Request $request)
{
    $payload = $request->getContent();           // raw body
    $signature = $request->header('Stripe-Signature');

    try {
        $event = Webhook::constructEvent(
            $payload,
            $signature,
            config('services.stripe.webhook_secret')
        );
    } catch (\UnexpectedValueException | SignatureVerificationException $e) {
        return response('Invalid', 400);
    }

    // ...store and queue the event
    return response('OK', 200);
}

Keep the signing secret in configuration, never in code, and use a separate secret per environment.

2. Exempt the route from CSRF, and only that route

Stripe is not a browser, so it cannot send a CSRF token. Exclude the webhook route from CSRF protection (in Laravel 11 and later this is done in bootstrap/app.php with validateCsrfTokens(except: [...])). Signature verification replaces CSRF protection for this one endpoint.

3. Respond fast, process later

Stripe expects a quick success response. If your handler does slow work, such as sending email, calling other APIs or updating several tables, the request may time out and Stripe will treat it as failed and retry. Do the minimum inside the request: verify, store, queue, return 200. Do the real work in a queued job, as described in my guide to Laravel queue architecture.

4. Deduplicate by event ID

Webhooks are delivered at least once, which means duplicates will happen. Every Stripe event has a unique id. Store it in a table with a unique index. If an insert fails because the ID already exists, you have already seen the event, so return 200 and do nothing. The same thinking applies to your own API endpoints, covered in API idempotency keys in Laravel.

5. Don't assume order

Events can arrive out of order. A "payment failed" event might land after a later "payment succeeded" event for the same invoice. Your handler should look at the current state in your database, and where the order matters, fetch the latest object from Stripe's API instead of trusting the sequence of events.

6. Make handlers safe to run twice

Even with deduplication, jobs can be retried. Write each handler so that running it twice leaves the same result: update by a stable key, use updateOrCreate, and check state before sending an email or granting access.

A reliable architecture

This is the shape I use:

Endpoint: verify the signature, insert the event into a stripe_events table (ID unique, payload, status), dispatch a job, return 200.
Job: load the stored event, run the handler for its type, and mark it processed. On failure, let the queue retry with backoff.
Handlers: one small class per event type you care about, such as invoice.paid, invoice.payment_failed, charge.refunded and checkout.session.completed.
Dead-letter view: a simple admin list of events that failed repeatedly, so a human can inspect and replay them.

Storing the raw event gives you an audit trail, and it lets you replay an event after fixing a bug instead of asking Stripe to resend it.

Which events to handle

Don't subscribe to everything. Start with the events that change what the customer can do or what you owe:

A checkout or payment completing successfully
A payment failing, so you can notify the customer and limit access if appropriate
Subscription updates and cancellations
Refunds and disputes

Fewer subscriptions mean less code to get wrong. Add more only when a feature needs them.

When Stripe can't reach you

If your endpoint returns an error or times out, Stripe retries the delivery over a period of time, with increasing gaps between attempts. You can also resend events from the Stripe dashboard. That safety net only helps if your endpoint is idempotent and your stored events show what happened. Add monitoring so you hear about a failing endpoint before customers do. My notes on observability for Laravel SaaS cover the alerts I set up.

Testing webhooks locally

Use the Stripe CLI to forward real test events to your local app and to trigger specific events on demand. Test these cases on purpose:

A valid event, an event with a bad signature and an event with a tampered body
The same event delivered twice
Events arriving out of order
A handler that throws an error halfway through
Your queue worker being stopped while events arrive

If all of these behave well in test mode, production will rarely surprise you.

Should you use Laravel Cashier?

If you are building standard subscriptions, Laravel Cashier already ships a webhook controller that verifies signatures and handles common subscription events. It is a good starting point, and you can extend it for your own events. For more custom flows, such as saving a card now and charging later, a hand-built handler gives you more control. My article on subscription billing architecture covers when each fits.

A real-world example

On the Stripe lead-billing project, I built a payment workflow that lets lead-generation clients save a payment method without an immediate charge, then automatically charges it when qualified leads are delivered. The status of successful and failed payments was kept in sync through webhook-driven updates. That is exactly the situation where trusting the webhook, not the browser, matters. Read the full Stripe lead billing case study.

Common mistakes to avoid

Parsing the JSON body before verifying the signature
Doing heavy work inside the webhook request
Treating the checkout redirect as proof of payment
Using one signing secret for test and live modes
Returning 500 for events you simply don't handle (return 200 and ignore them)
Having no way to see or replay failed events

Key takeaways

Webhooks, not redirects, are the source of truth for payment state.
Verify the signature, respond fast, then process in a queue.
Deduplicate on the event ID and make every handler safe to run twice.
Store raw events so you can audit and replay.
Monitor the endpoint and test failure cases before launch.

If you want a payment integration that stays correct when things go wrong, book a call and we can review your flow together.

Originally published at aqibjavaid.site.

Rewrite or Refactor a Legacy Application? How to Decide

Fri, 16 Oct 2026 14:55:27 +0000

Every business with an ageing application eventually faces the same question: do we rewrite or refactor the legacy application? Get it wrong and you either burn a year rebuilding something that already worked, or you pour money into patching a system that cannot be saved.

I handle this decision as part of legacy application modernization work, and the honest answer is almost never "rewrite everything" or "leave it alone". This guide gives you a practical way to decide, the questions I ask, and the middle path that usually wins.

What "legacy" actually means

Old code is not automatically legacy code. An application is legacy when it is hard to change safely. Typical signs:

Nobody dares to deploy on a Friday, or at all
Only one person understands how it works
The framework or language version no longer gets security updates
Simple changes take weeks because everything is tangled together
There are no tests, so every change is a gamble
Hosting and dependencies are frozen because upgrading might break things

If the app is old but stable, tested and easy to change, it is not your problem. If it is new but a mess, it might be.

The three options, in plain terms

Refactor in place. Improve the existing code step by step without changing what the system does: add tests, clean up the worst areas, upgrade dependencies.
Rewrite from scratch. Build a new system and switch over when it is ready.
Modernise incrementally. Replace the system piece by piece while the old one keeps running. This is often called the strangler pattern, described well in Martin Fowler's write-up of the Strangler Fig approach.

Most teams think they have two choices. The third is what usually works.

Why big-bang rewrites fail so often

A full rewrite looks attractive: clean code, modern tools, no baggage. The problem is that the old system contains years of quiet business knowledge: edge cases, workarounds, rules nobody wrote down. Joel Spolsky made this argument in his classic essay Things You Should Never Do, Part I, and it still holds up.

In practice, rewrites go wrong for predictable reasons:

The old system keeps changing while you build the new one, so you are chasing a moving target.
You ship nothing for months, so the business pays but sees no value.
Hidden behaviour is lost because nobody remembers why it worked that way.
Scope grows, because a rewrite invites "while we're at it" features.

That does not mean never rewrite. It means be sure you must, and limit the blast radius.

A decision framework you can use this week

Score your system on these questions. I use them in audits.

1. Can the system still do its job? If it works and the business is not blocked, you have time to move carefully. If it is failing daily, you may need to stabilise first.

2. Is the technology end-of-life? An unsupported framework or language version is a security and hiring risk. That pushes you toward upgrading or replacing, not ignoring.

3. Is the data model sound? A good database under a messy application is a great position. A broken data model is a much bigger problem than ugly code.

4. Can you test it? If you can add tests around key flows, refactoring becomes safe. If the code cannot be tested at all, that is a strong signal to replace parts of it.

5. How tangled are the pieces? Systems with clear boundaries can be replaced one module at a time. A single ball of mud is harder.

6. What does the business need next? If the next year's roadmap is mostly new features, spend effort where those features land, not on parts nobody touches.

7. Who knows the system? If that knowledge is walking out the door, document and test first, whatever you choose.

When refactoring is the right call

Choose refactoring when:

The framework is still supported or has a clear upgrade path
The data model is sound
The pain is concentrated in a few areas
You can put tests around the critical flows

I often start with exactly this: map the dependencies, add tests around the riskiest workflows, fix the worst hotspots, and upgrade in steps. My Laravel upgrade checklist walks through that approach for older Laravel apps.

When a rewrite is justified

A rewrite makes sense when:

The platform is end-of-life with no sensible upgrade path
The architecture fundamentally cannot support what the business needs
The system is small enough to rebuild in a short, fixed window
The code is so untestable that incremental change is not possible

Even then, I prefer to rebuild in slices, with the old system running beside the new one.

The incremental path most businesses should take

The approach I recommend most often has five steps:

Audit first. Understand the workflows, the database, the dependencies and the risks before deciding anything.
Stabilise. Fix security gaps, add monitoring and backups, and make deployments repeatable.
Add tests around the flows that matter most.
Replace one slice at a time. Pick a self-contained module, rebuild it in the new stack and route traffic to it.
Retire the old parts once the new ones have proven themselves.

Each step delivers something the business can see, and each one can be paused or reversed.

What drives the cost either way

I will not quote a number without seeing the system, but these factors move cost and timeline the most:

Size and complexity of the application, especially the number of distinct workflows
Test coverage, because untested code costs more to change safely
Data migration, since moving and validating years of records is often the riskiest step
Integrations with payment, shipping, CRM and other third-party services
How much downtime the business can tolerate during the switch
Documentation and access, because missing knowledge slows everything down

An audit before the main work is usually the cheapest way to turn these unknowns into a plan you can budget.

A real-world example

On the PPCWA freight-forwarding audit, I was brought in to audit and stabilise a nearly completed Core PHP and MySQL platform. The work focused on understanding the existing system first: workflows, database structure, frontend maintainability, dependencies and configuration. I also assessed the architectural path toward a future Laravel migration. The point was to decide with evidence instead of opinion. I describe a related migration in migrating a legacy Core PHP platform to Laravel and a Laravel-specific version in Laravel 5 migration strategy.

Questions to ask any developer or agency

If someone recommends a rewrite, ask:

What did you find in the existing system that cannot be improved?
How will we keep the business running during the work?
Which parts will go live first, and when?
How will you protect the data and the undocumented business rules?
What is the plan if the project overruns?

A good partner answers with specifics. A weak one answers with enthusiasm for new technology.

Key takeaways

"Legacy" means hard to change safely, not just old.
Big-bang rewrites fail because they lose hidden business knowledge and deliver late.
Audit first, then choose refactor, rewrite or incremental replacement with evidence.
Incremental modernisation is usually the lowest-risk option.
A sound data model and testable flows tilt the decision toward refactoring.

If you are weighing this decision for your own application, book a call and I will tell you which path I would take and why.

Originally published at aqibjavaid.site.

My Journey as a PHP Developer: Building Solutions Through Code

Fri, 09 Oct 2026 12:40:54 +0000

As a PHP developer, I enjoy turning ideas into functional websites and building backend solutions that solve real-world problems. For me, programming is not just about writing code; it’s about understanding challenges, finding practical solutions, and creating applications that make everyday tasks easier.

I enjoy working on dynamic websites, developing backend functionality, and exploring ways to make applications more efficient, reliable, and user friendly. I believe that clean, maintainable code is the foundation of good software development, and I always try to improve the way I approach problems and build solutions.

Technology is constantly evolving, which makes software development an exciting journey. I enjoy learning new tools, exploring different approaches, debugging problems, and discovering better ways to write code. Every challenge is an opportunity to learn something new and become a better developer.

Beyond coding, I value sharing knowledge, exchanging ideas, and connecting with other developers. I believe we can grow faster when we learn from each other's experiences, discuss different perspectives, and support the developer community.

My goal is to keep improving my PHP development skills, build meaningful projects, and create solutions that deliver real value.

I’m always learning, always building, and always looking for the next problem to solve.

I'd love to connect with fellow developers, hear about your projects, and learn from your experiences. Let's keep building, sharing, and growing together!

AI Email Classifier Cost per 1,000 Messages: Real Math

Thu, 08 Oct 2026 15:50:00 +0000

For 1,000 typical text emails, the model API can cost roughly $0.05 to $1.08, or about PHP 3 to PHP 66 at a rounded PHP 61.55 per US dollar. That estimate assumes 900 input tokens and 30 output tokens per message, no attachments, no retries, and one classification call per email.

Partner disclosure. This guide includes a partner link to n8n Cloud. If you sign up through it, I may earn a commission at no extra cost to you.

The low token bill is real, but it is not the whole operating cost. Your automation platform, monitoring, human review, and the consequences of a wrong route can cost much more than inference. Prices and exchange rates may change, so keep the formula and replace the rates instead of trusting a static total.

Practical answer: budget about $0.10 to $0.25 per 1,000 ordinary emails for a small classification model, then evaluate accuracy on your own inbox. A model that costs five cents but misroutes valuable leads is not the cheaper option.

The workload behind the estimate

A useful comparison needs the same input and output size for every model. This article uses a typical business email workload rather than each provider's most flattering example.

Component per email	Assumed tokens	What it includes
Classification instructions	250 input	Category names, definitions, edge-case rules, and output instructions
Email content	650 input	Subject, cleaned body, and a small amount of sender context
Classification result	30 output	One label plus compact structured fields such as reason and review flag
Total for 1,000	900,000 input 30,000 output	No attachment extraction, second model call, retry, or human-written reply

Token counts vary by provider and tokenizer. Treat 900 and 30 as planning inputs, then replace them with usage data from the API response or provider dashboard. Long quoted threads, HTML, signatures, disclaimers, and pasted documents can multiply the input without improving the decision.

The cost formula

Provider pages normally quote text prices per one million tokens. The calculation is:

cost = (input_tokens / 1,000,000 × input_rate)
     + (output_tokens / 1,000,000 × output_rate)

Typical 1,000-email workload:
cost = (900,000 / 1,000,000 × input_rate)
     + (30,000 / 1,000,000 × output_rate)

Example for OpenAI GPT-5.4 nano at the rates checked on July 20, 2026:

input  = 0.9 × $0.20 = $0.1800
output = 0.03 × $1.25 = $0.0375
total  = $0.2175, rounded to $0.22 per 1,000 emails

Current model API comparison

These totals use standard synchronous API pricing, without free tiers, batch discounts, cached-input discounts, regional uplifts, or taxes. The selected models are small or cost-focused options that can plausibly handle classification. Model quality is not equivalent, so the last column is a cost comparison, not a ranking.

Rate check: every provider price in this table was checked against the linked official source on July 20, 2026. The PHP estimates use a BSP rate of PHP 61.548 per US dollar checked on the same date. To update any peso estimate, use PHP estimate = USD total × current PHP per USD. For example, $0.2175 × 61.548 = PHP 13.39.

Model	Input / 1M	Output / 1M	Typical 1,000 emails
Groq Llama 3.1 8B Instant	$0.05	$0.08	$0.047 / about PHP 3
Google Gemini 2.5 Flash-Lite	$0.10	$0.40	$0.102 / about PHP 6
OpenAI GPT-5.4 nano	$0.20	$1.25	$0.218 / about PHP 13
Anthropic Claude Haiku 4.5	$1.00	$5.00	$1.05 / about PHP 65
OpenAI GPT-5.6 Luna	$1.00	$6.00	$1.08 / about PHP 66

OpenAI describes GPT-5.4 nano as suitable for classification and other simple high-volume tasks. Its newer GPT-5.6 guidance points cost-sensitive new workloads toward Luna, but Luna costs more in this narrow token calculation. Test both only if the quality gain matters for your categories. Google calls Gemini 2.5 Flash-Lite its smallest and most cost-effective model for at-scale use. Anthropic's current Haiku tier costs more per token, while Groq's Llama 3.1 8B rate is the lowest in this selected set.

Email length changes the bill, but not equally

Output is tiny for a classifier, so input length usually drives the total. This sensitivity table keeps output compact while changing the amount of text sent to the model.

1,000-email workload	Input / output	Gemini 2.5 Flash-Lite	GPT-5.4 nano	Claude Haiku 4.5
Short	400k / 25k	$0.05	$0.11	$0.53
Typical	900k / 30k	$0.10	$0.22	$1.05
Long	2M / 40k	$0.22	$0.45	$2.20

The long scenario is still inexpensive as a token bill. It is also a warning: paying to resend an entire quoted conversation may expose unnecessary customer data and make the classification noisier. Clean the message before the model call.

What the token estimate leaves out

Automation platform cost

n8n Cloud is priced by workflow executions, not by node or step. If one incoming email starts one production workflow, 1,000 emails normally consume 1,000 executions. The model API remains a separate provider charge when you connect your own credential. If you already have unused execution capacity, the incremental platform cost may be zero. If the classifier forces a plan upgrade, the subscription difference can dwarf a 22-cent model bill.

One n8n execution can contain several items, but the Text Classifier documentation says each item is passed to the model. Grouping emails into one scheduled execution can reduce execution usage, while the token charge still follows the number and size of classified items.

Retries and output repair

A failed request, provider retry, or second-pass validation adds another call. n8n's Text Classifier has an Enable Auto-Fixing option that sends a schema parsing error back to the model and asks it to repair the output. That is useful, but it means the estimate above is no longer one call per email when repair is triggered. Measure the repair rate before assuming it is free.

Human review and mistakes

Suppose a reviewer spends 30 seconds on 10% of 1,000 emails. That is 50 minutes of work. Even at a modest internal hourly rate, review costs far more than the API tokens. The review may still be a good investment if it catches invoices routed to sales, urgent complaints marked as routine, or valuable leads sent to the wrong queue.

The correct metric is not only cost per 1,000 messages. Track cost per correctly classified message, manual-review rate, false-negative rate for urgent categories, and the operational cost of each error.

A simple n8n cost-measurement workflow

n8n already has a Text Classifier root node. It accepts an input prompt, category names and descriptions, optional multiple classes, an Other branch for unclear matches, a custom system prompt, and optional auto-fixing. For cost measurement, keep the workflow smaller than a full email router:

Email trigger or scheduled inbox fetch
  → Edit Fields: subject + cleaned body + minimal sender context
  → Text Classifier: named categories and descriptions
     ↳ connected small chat model
  → Log: provider, model, input tokens, output tokens, category
  → Route Other and selected high-risk categories to review

The separate AI email routing guide covers the downstream workflow. This article stays focused on cost measurement and model choice.

Use categories that are testable

Define categories by the action they trigger. For example: sales_lead, support, billing, urgent_complaint, and other_review. Give each category a short description and two or three edge rules. Do not ask the model for a paragraph when one label and a compact reason are enough.

Keep Allow Multiple Classes To Be True off when the business requires one owner. Use the documented Other branch instead of discarding an unclear item. Discarding may look efficient, but it can hide the messages most in need of review.

Log actual usage

Provider response fields differ, so inspect the output from your selected n8n chat-model node or the provider dashboard. Record input tokens, output tokens, model ID, retry count, latency, chosen category, and the reviewer's corrected category. Recalculate weekly:

observed cost per 1,000 =
  total provider cost / classified messages × 1,000

cost per correct classification =
  (provider + platform allocation + review labor) / correct decisions

Reduce cost without weakening the classifier

Use deterministic rules first. Known senders, exact aliases, and clear invoice mailbox rules do not need an LLM.
Remove quoted history. Classify the newest message plus only the minimum thread context required for meaning.
Strip HTML and signatures. Boilerplate consumes input and can introduce misleading terms.
Return a compact schema. A label, short reason, and review flag are enough for routing.
Do not add search or tools. An inbox classifier should not browse the web or call unrelated tools.
Measure auto-fixes and retries. A low base price can double if malformed output repeatedly triggers a second call.
Test a small model first. Upgrade only when a measured accuracy gap is worth the higher rate.

Choose the model by evaluation, not the price table

Start with at least 100 to 200 representative emails that a person has already labeled. Include short replies, forwarded threads, vague subjects, multilingual messages, promotions, complaints, and categories that are easy to confuse. This is an operational starting point, not a universal statistical guarantee.

Test	What to measure	Decision
Overall accuracy	Correct labels divided by all tested messages	Useful for orientation, not enough for rare urgent classes
Per-category recall	How many real messages in a category the model found	Prioritize billing, complaints, security, and other costly misses
Other or review rate	Share of messages that need a person	Convert the review share into minutes and labor cost
Correction stability	Whether prompt or model changes improve the same held-out set	Use a versioned test set before changing production

If two models are close, choose the simpler operational fit: supported credential, stable model ID, acceptable latency, data-processing requirements, and clear usage reporting. A few extra cents per 1,000 emails can be a sensible trade for fewer manual reviews.

Questions small teams usually ask

Can the classifier really cost less than one dollar?

Yes. A classification output is short, and small models have low token rates. The estimate stops being valid when you send long histories, extract attachments, ask for generated replies, use a larger model, or trigger repair and retry calls.

Does n8n include the model tokens?

Do not confuse n8n's AI Assistant credits with the third-party model used inside your production workflow. With your own OpenAI, Gemini, Anthropic, or Groq credential, the model provider meters the API usage. n8n Cloud separately counts workflow executions according to its current plan rules.

Should I use the cheapest model?

Use the cheapest model that passes your labeled evaluation and operational requirements. Price alone cannot tell you whether a model understands your category boundary, language mix, or unusual messages.

Should low-cost classifications send automatic replies?

Classification and outbound sending are separate risk decisions. Route first. If AI also drafts a customer-facing response, use a duplicate-safe human approval gate until measured evidence supports narrower exceptions.

Sources checked

n8n Cloud for small teams

Measure the classifier before you scale it

n8n Cloud is the simplest starting point if you want to connect an inbox, test categories, and log real usage without maintaining a server. Affiliate disclosure: I may earn a commission if you sign up through this link, at no extra cost to you.

<a href="https://n8n.partnerlinks.io/6mg2xng7s1m6" target="_blank" rel="sponsored noopener" class="btn b

How Much Can You Trust a Filesystem Baseline? Design Notes from Laravel Scalpel

Thu, 08 Oct 2026 04:44:43 +0000

A file hash only means something if you trust the moment it was recorded. That sounds obvious, but it is the part of integrity checking that people most often skip. Here are the design decisions behind the baseline feature in Laravel Scalpel, an open-source intrusion evidence scanner for Laravel. Scalpel is now at v1.11.0, and the trade-offs below came up repeatedly in issues and in an independent review by Laravel News.

What a baseline records

scalpel:baseline stores three things for each included file: its SHA-256 hash, its size, and its modification time. Later, scalpel:diff compares the live files against that record and reports files that were added, modified, or deleted.

php artisan scalpel:baseline
php artisan scalpel:diff

The idea is simple. Content scanners tell you whether a file looks suspicious. A baseline tells you whether a file changed, even if it looks perfectly normal. A backdoor hidden in a legitimate file will not match any pattern, but it will not match the old hash either.

Decision 1: what to leave out

A baseline that reports every log rotation is a baseline you will stop reading. By default, frequently changing paths such as logs, sessions, compiled views, and storage/app are excluded.

vendor/ gets different treatment. It is skipped by the content scanners, because scanning thousands of third-party files produces noise. But it stays in the baseline comparison. If someone drops a file into an installed package, you still see it in the diff.

Decision 2: strict or fast hashing

By default, Scalpel runs in strict mode and re-hashes every file on each comparison. That is the most reliable option and also the slowest.

The --fast option first compares size and modification time, and reuses the old hash when both match. It saves work, but it has a known blind spot: an attacker who edits a file and restores its original size and modification time can slip past the baseline comparison. Other scanners may still catch the file by its content or location, but the baseline alone will not.

A practical rule: use strict mode where the result matters, such as scheduled integrity checks, and --fast only where speed matters more, such as frequent local runs.

Decision 3: sign the baseline

If an attacker can rewrite the baseline, the diff becomes meaningless. Scalpel can HMAC-sign baselines and JSON reports when SCALPEL_SIGNING_ENABLED is true. The key goes in SCALPEL_SIGNING_KEY, and it should be a dedicated key, not your APP_KEY.

When signing is on, scalpel:diff verifies the baseline before using it. A missing or invalid signature is reported as CRITICAL. For saved JSON reports, scalpel:verify checks the signature.

Two details matter in practice. First, turn on signing before you create the first baseline, otherwise you have an unsigned record to start from. Second, signing has a clear limit: it detects a baseline regenerated without the key, but it cannot help if the attacker can read the key or modify the scanner itself.

Decision 4: when to refresh

A baseline is a record of a state you trust, so it has to be refreshed deliberately. The suggested flow after each deployment is to run php artisan optimize, then scalpel:baseline --force to replace the old record. Until a baseline exists, both scan and diff report a MEDIUM finding telling you to create one.

Never create a baseline on a server you suspect is already compromised. You would be recording the attacker's files as normal.

The trust boundary

All of this runs in the same process, with the same permissions, as your application. Anyone who can change your code can also change the scanner. So the strongest setup moves the trust boundary outside the app:

Trigger scans from outside the server, for example from CI or a scheduler on another machine.
Keep code directories read-only where possible.
Send reports and baselines to storage the server cannot write to.

A scanner like this detects evidence of an intrusion. It does not block or contain one.

Try it

composer require hryagstn/laravel-scalpel
php artisan vendor:publish --tag=scalpel-config

Requires PHP 8.2 or later and supports Laravel 10 to 13.

If you have a case where the baseline gives noisy or misleading results, please open an issue. I covered what the individual scanners look for in a separate post on DEV: https://dev.to/harryagustiana/what-a-filesystem-scan-can-and-cannot-tell-you-after-a-laravel-intrusion-1hn5

Source: https://github.com/hryagstn/laravel-scalpel

Write Your Game Lore Like an Encyclopedia, Not a Novel

Thu, 01 Oct 2026 15:52:21 +0000

Plenty of us here have tried giving a game character an LLM brain, and the first version usually starts inventing its own world within ten minutes. This post is about a fix that is mostly a writing problem rather than a code problem: how you structure lore so the model gets the right facts at the right moment.

How Retrieval Picks What the Model Sees

Pasting your whole world into a system prompt stops working once the world gets big. The usual answer is retrieval. Lore is split into chunks, each chunk gets an embedding, and on every player message the server finds the chunks closest in meaning and passes only those to the model alongside the conversation.

The catch is that retrieval can only return what your chunks contain, and a chunk's embedding is an average of everything in it. A chunk about one tavern has a sharp fingerprint. A chunk that covers the tavern, the war, three characters and a currency system has a blurry one, and it either matches everything a little or nothing well.

One Topic per Chunk

So write lore the way an encyclopedia is written. One entry for each place, one for each character, one for each rule of the world, each short enough to stand on its own. Name the subject in the entry itself, not just in a heading, so the chunk still makes sense when it is pulled out alone.

Novel style writing works against you here. A beautiful chapter that introduces five characters through a conversation is hard for retrieval to use, because the facts about any one character are scattered across it. Keep the prose for the narrator to produce, and keep the source material plain.

Tags help too. Put the world bible in one collection, item and rules references in another, and point each bot only at what it needs. When a character fails to know something, search the tag directly with the same prompt and you will usually see the problem in seconds: the fact was never chunked on its own.

Keep Temporary State Out of the Lore

Lore should hold what is always true. What is true for this player, or true only tonight, belongs somewhere else. Per player memories handle the first, and a per request rule string like "the player is wounded and cannot fight" handles the second without rewriting the world.

Mixing them is how lore rots. Once the knowledge base contains "the bridge is burned" from one player's session, every other player inherits it.

Wrapping Up

If you want to try this without building the plumbing, AbraTabia AI Storyteller is a free open source server, one PHP app and one SQLite file, that handles chunking, retrieval, per player memory and turn based play for up to 10 players behind one chat endpoint. Write the lore as entries, let retrieval do the selecting, and your narrator will stay inside your world.

JSON vs MessagePack in Laravel: A Practical API Benchmark

Thu, 24 Sep 2026 13:39:50 +0000

JSON is the right default for most Laravel APIs. It is readable, supported everywhere, easy to debug, and familiar to every client.

MessagePack is worth considering when payload size, bandwidth, or a controlled client ecosystem matters. It is a compact binary format that keeps a schema-free data model, but it is not automatically faster or smaller for every workload.

This article compares both formats in a Laravel API and shows how to adopt MessagePack without breaking existing JSON clients.

The examples use Laravel Msgpack, an open-source package that adds opt-in MessagePack content negotiation, request decoding, safety limits, and a repeatable benchmark command.

The short answer

Use JSON when:

Your clients include browsers, third-party integrations, or unknown consumers.
Human-readable responses and simple debugging are important.
Your payloads are already small or compressed effectively.
You do not control the client decoder and deployment environment.

Use MessagePack when:

You control the clients and can ship a binary decoder.
Network transfer size is important for mobile, edge, or internal services.
Your payloads are large enough for serialization and decoding trade-offs to matter.
You want to keep JSON compatibility while allowing capable clients to opt in.

For many Laravel applications, the best answer is not choosing one format globally. Keep JSON as the default and negotiate MessagePack per request.

What are we comparing?

JSON is a text representation. It is self-describing, easy to inspect, and supported by the web platform.

MessagePack is a binary representation. It encodes the same basic data model using compact type markers and lengths instead of textual punctuation and names repeated in a text format.

The comparison should use the same data, the same PHP runtime, and the same operation count. Otherwise, the result is a benchmark of different workloads rather than a comparison of formats.

Add MessagePack to Laravel

Install the package:

composer require smmehdisharifi/laravel-msgpack

Apply the middleware to a route or route group:

use Illuminate\Support\Facades\Route;

Route::middleware('msgpack')->get('/api/profile', function () {
    return [
        'id' => 1042,
        'name' => 'Laravel MessagePack',
        'roles' => ['maintainer', 'developer'],
        'features' => [
            'negotiation' => true,
            'fallback' => 'json',
        ],
    ];
});

The route does not need separate JSON and MessagePack controllers. Existing clients continue to receive JSON:

curl -i http://localhost/api/profile

A capable client opts into MessagePack with the Accept header. Save the binary response instead of printing it as terminal text:

curl -sS -D - \
  -H 'Accept: application/msgpack' \
  -o profile.msgpack \
  http://localhost/api/profile

The negotiated response includes:

Content-Type: application/msgpack
Vary: Accept

Vary: Accept is important because a cache must not serve a MessagePack response to a client that asked for JSON, or the other way around.

How content negotiation works

The middleware keeps the migration opt-in:

A client that does not request MessagePack receives JSON.
A client that sends Accept: application/msgpack receives a binary response when the route supports the middleware.
If both formats are accepted, the higher quality factor wins.
Wildcards are evaluated by media-type specificity.
A request that rejects every supported representation receives 406 Not Acceptable.

The same negotiation applies to relevant error responses, including unmatched routes and route exceptions. Incoming requests can use application/msgpack or the legacy application/x-msgpack media type.

Run a repeatable benchmark

Laravel Msgpack includes an Artisan command so the comparison is easy to reproduce:

php artisan msgpack:benchmark --iterations=1000 --json

The command uses a deterministic API-shaped fixture with nested values and Unicode text. It measures:

Raw JSON and MessagePack byte size.
Encode time per iteration.
Decode time per iteration.
Optional gzip size and compression timings when ext-zlib is available.

The command warms each operation once before timing it. It reports per-iteration timings so runs with different iteration counts remain comparable.

Results from this package

The following result was produced by the package benchmark on PHP 8.4 with rybakit/msgpack 0.7.2 and 1,000 iterations:

Measurement	JSON	MessagePack	Difference
Raw payload	591 B	435 B	26.40% smaller
Encode time	0.002 ms	0.009 ms	JSON faster
Decode time	0.003 ms	0.008 ms	JSON faster
Gzip payload	377 B	371 B	1.59% smaller
Gzip compress time	0.009 ms	0.010 ms	Nearly equal
Gzip decompress time	0.004 ms	0.003 ms	Nearly equal

There are three useful conclusions here.

First, MessagePack is noticeably smaller before compression for this fixture. That can matter when transfer size is the bottleneck.

Second, the smallest representation is not automatically the fastest representation. For this small payload, JSON serialization is faster in the measured run.

Third, compression changes the size comparison. Once gzip is applied, the gap is much smaller because gzip already removes a lot of JSON's repetitive syntax.

These are indicative measurements, not universal promises. A real decision should use payloads, client runtimes, compression settings, and network conditions that match your application.

Decode MessagePack requests

MessagePack request bodies are decoded automatically when the middleware is applied:

use Illuminate\Http\Request;

Route::middleware('msgpack')->post('/api/profile', function (Request $request) {
    return [
        'received' => $request->msgpack(),
        'name' => $request->input('name'),
    ];
});

Map payloads are also merged into Laravel's normal request input. The original decoded value remains available through request()->msgpack(), including scalar and list payloads.

The package rejects malformed payloads before they reach the route handler. Configurable request size, nesting-depth, and value-count guards provide additional protection against oversized or unexpectedly deep input.

When a route must always return MessagePack

Negotiation is useful when the same endpoint serves different clients. For a route that should always return MessagePack, use the response macro:

return response()->msgpack([
    'message' => 'Created',
], 201, [
    'X-Request-Id' => $requestId,
]);

Direct serialization is also available through the facade:

use Msgpack;

$packed = Msgpack::encode($data);
$unpacked = Msgpack::decode($packed);

A practical decision guide

Do not change every endpoint to MessagePack because a synthetic benchmark produced a smaller payload. Instead, measure the part of the system that matters.

Choose JSON first when interoperability, browser support, observability, or simple debugging is the priority.

Test MessagePack when bandwidth, payload volume, or mobile transfer cost is important and the clients are controlled.

Keep both formats when you serve a mixed ecosystem. JSON remains the safe default, while clients that understand MessagePack can opt into it without a second controller implementation.

Limitations to keep in mind

MessagePack is not encryption. Sensitive data still needs transport security and application-level authorization.

Binary responses are less convenient to inspect in logs and command-line terminals. Save them to a file or decode them with a client library.

Compression may reduce the practical size advantage. Measure compressed and uncompressed responses for the transport configuration you actually deploy.

The benchmark fixture is intentionally stable, not universal. A list-heavy payload, a text-heavy payload, a large nested object, or a response with repeated keys can produce different results.

Try it in your project

Install Laravel Msgpack, apply the msgpack middleware to one endpoint, and compare both representations with your real data.

The repository contains the full implementation, compatibility matrix, configuration reference, safety limits, and benchmark command:

https://github.com/smmehdisharifi/laravel-msgpack

If the package helps your API, a GitHub star helps other Laravel developers discover it.

Multiple Image Uploads in WPForms Lite: How I Built Multimage

Wed, 23 Sep 2026 19:24:10 +0000

WPForms Lite is one of the most popular free form builders in WordPress, but it has one gap that keeps coming up: there's no file upload field. If you want visitors to attach photos to a contact form, a support request, or a portfolio submission, the usual answer is "upgrade to Pro."

I wanted a lighter answer for that one use case, so I built Multimage – Image Uploads for WPForms, a free plugin on WordPress.org that adds a Multi Image Upload field to the WPForms builder, Lite included.

What it does

Once activated, a new Multi Image Upload field appears in the WPForms Standard Fields panel. Drag it into any form and configure it per field: maximum number of uploads, allowed file extensions, and maximum file size in MB.

On the front end, visitors can pick several images at once, see them listed with individual remove buttons, and submit. On the admin side, image URLs show up in the {all_fields} email template, and the images themselves are attached to notification emails.

The tricky part: AJAX submission

WPForms can submit forms with or without AJAX, and files don't travel nicely through form serialization. Building an upload field that only works in one mode would have been fragile.

So Multimage doesn't wait for the form submit. The flow looks like this:

When a visitor selects images, each file is uploaded immediately to a temporary folder through a secured AJAX endpoint.
The endpoint returns a lightweight token for each file.
Only those tokens travel with the form submission, not the files.
When the submission succeeds, the files are moved from the temp folder into the standard WordPress uploads directory (wp-content/uploads/year/month).

Because the heavy lifting happens before submit, it doesn't matter whether AJAX submission is on or off. Nothing gets lost.

Security decisions

Accepting files from anonymous visitors is where most upload plugins get into trouble, so validation happens server-side regardless of what the field settings say:

Content-based MIME detection, not just trusting the file extension
A hard image-only whitelist: jpg, jpeg, png, gif, and webp. Even if someone misconfigures the field, non-image files are rejected
Size limits enforced on the server
Automatic cleanup: temporary uploads that were never attached to a successful submission are deleted after 24 hours, so abandoned forms don't fill up your disk

Why images don't go into the Media Library

A deliberate choice: submitted images are saved to the uploads directory but are not registered as Media Library attachments. Visitor submissions are form data, not site content, and a busy form shouldn't bury your actual media under hundreds of random photos.

Where it fits

Any form where visitors need to send more than one photo: gallery or portfolio submissions, job or program applications, product damage and support requests, property or event photo forms. Need a single profile photo and a larger gallery in one form? Add two Multi Image Upload fields with different limits.

Privacy

Everything stays on your server. Images live in your uploads directory and are only emailed where you've configured WPForms notifications. No external services are involved.

Try it

Plugin: Multimage – Image Uploads for WPForms
Requirements: WordPress 5.8+, PHP 7.4+, WPForms Lite or Pro

It's a 1.0 release, so feedback, bug reports, and feature requests on the support forum are very welcome.

Multimage is an independent, third-party add-on and is not affiliated with, endorsed by, or sponsored by WPForms or Awesome Motive, Inc. "WPForms" is used only to describe compatibility.

Building explainable duplicate detection in Laravel (no ML, no packages)

Mon, 21 Sep 2026 11:53:07 +0000

I built a rental listing platform with Laravel 13, PHP 8.4, PostgreSQL, Redis, and Sanctum.

One problem quickly became obvious:

Agents could post the same property multiple times.

In Nigeria, property listings often don't have precise street addresses. A typical listing might look like:

"2-bedroom flat, Yaba. Near Yaba Tech."

There may be no house number and sometimes no street name.

Instead, people identify properties using a combination of:

Area
Landmark
Property type
Number of bedrooms
Rent

That makes duplicate detection a little different from what you might build for a marketplace with structured addresses.

I wanted a solution that was:

Explainable
Easy to tune
Easy for reviewers to understand
Independent of machine learning
Cheap enough to run whenever a listing changes

So I built a rule-based duplicate detection system using Laravel and PHP.

The Architecture

The basic workflow is:

Property created/updated
        ↓
Find candidate properties
        ↓
Calculate similarity score
        ↓
Store score + explanation
        ↓
Classify match
        ↓
Reviewer confirms/rejects

The important distinction is that I don't compare every property against every other property.

Instead, I first narrow the candidate set using database queries and then perform the more expensive comparison in PHP.

1. Creating a Property Fingerprint

Because Nigerian rental listings don't always have reliable addresses, I needed another way to represent a property's identity.

I started with:

Area + Landmark + Bedrooms + Property Type

These fields are normalized and hashed into a fingerprint.

class PropertyFingerprintService
{
    public static function generate(array $data): string
    {
        $parts = [
            strtolower(trim($data['area'] ?? '')),
            strtolower(trim($data['landmark'] ?? '')),
            (string) ($data['bedrooms'] ?? ''),
            strtolower(trim($data['property_type'] ?? '')),
        ];

        return hash('sha256', implode('|', $parts));
    }
}

For example:

Yaba | Near Yaba Tech | 2 | Flat

becomes a deterministic SHA-256 hash.

This gives us a fast way to identify listings that have the same core identity fields.

An Important Database Lesson

Initially, I made the fingerprint column unique:

$table->string('fingerprint')->unique();

That turned out to be a mistake.

If an agent tried to create the same property again, the database rejected it.

That sounds useful until you remember the purpose of the feature.

I don't want the database to prevent the duplicate.

I want the duplicate to exist so that the platform can surface it for human review.

So I changed the migration to:

$table->dropUnique(['fingerprint']);
$table->index('fingerprint');

Now multiple properties can have the same fingerprint.

The database helps us find duplicates instead of blocking them.

That distinction is important for any system where duplicates are supposed to be reviewed rather than automatically rejected.

2. Candidate Selection

The next problem is scale.

Imagine the platform has 100,000 properties.

Comparing one new property against all 100,000 would obviously be wasteful.

Instead, I narrow the candidates using fields that are already indexed.

The query looks roughly like this:

public function findCandidates(Property $property): EloquentCollection
{
    return Property::query()
        ->where('id', '!=', $property->id)
        ->where(function ($query) use ($property) {
            $query->where('fingerprint', $property->fingerprint)
                ->orWhere(function ($inner) use ($property) {
                    $inner->where('area', $property->area)
                        ->where('bedrooms', $property->bedrooms);
                });

            if ($property->landmark) {
                $query->orWhere('landmark', $property->landmark);
            }
        })
        ->get();
}

The query looks simple, but there is an important Laravel detail here.

Group your `orWhere` clauses

The exclusion:

->where('id', '!=', $property->id)

needs to apply to every branch of the candidate query.

That's why the orWhere conditions are wrapped in a closure:

->where(function ($query) {
    // OR conditions
});

Without that grouping, you can accidentally generate logic equivalent to:

id != ?
AND fingerprint = ?
OR area = ?

The OR can escape the intended grouping and return the current property itself.

For queries with multiple OR conditions, explicit grouping is worth paying attention to.

3. Scoring the Candidates

Once I have a relatively small candidate set, I score each property against the new listing.

The scoring model is intentionally simple.

Signal	Points
Same area	25
Same landmark	20
Same bedrooms	15
Rent within 10%	20
Description similarity	20
Maximum	100

The goal isn't to produce a statistically perfect probability.

The goal is to produce a number that a reviewer can understand.

Keeping the Explanation

Before calculating the score, I create a details structure:

$details = [
    'area_match' => false,
    'landmark_match' => false,
    'bedrooms_match' => false,
    'rent_match' => null,
    'rent_difference_percent' => null,
    'description_similarity' => 0.0,
    'fingerprint_match' => false,
];

This is important because storing only:

confidence_score = 87

doesn't tell us much.

Instead, we can store:

{
    "area_match": true,
    "landmark_match": true,
    "bedrooms_match": true,
    "rent_match": "within_10_percent",
    "rent_difference_percent": 4.2,
    "description_similarity": 87.4,
    "fingerprint_match": false
}

Now the reviewer can understand why the system flagged the properties.

4. Comparing the Area

The area comparison is straightforward:

if (strcasecmp(trim($a->area), trim($b->area)) === 0) {
    $details['area_match'] = true;

    $points += self::WEIGHT_AREA;
}

With:

private const WEIGHT_AREA = 25;

5. Comparing Rent

Rent shouldn't need to be exactly the same.

Different agents might advertise the same property at slightly different prices.

For example:

Agent A: ₦1,500,000
Agent B: ₦1,550,000

These listings could still represent the same property.

So I calculate the percentage difference:

if ((float) $a->rent > 0 && (float) $b->rent > 0) {
    $diff = abs((float) $a->rent - (float) $b->rent)
        / max((float) $a->rent, (float) $b->rent);

    $details['rent_difference_percent'] = round($diff * 100, 2);

    if ($diff <= 0.10) {
        $details['rent_match'] = 'within_10_percent';

        $points += self::WEIGHT_RENT;
    } elseif ($diff <= 0.20) {
        $details['rent_match'] = 'within_20_percent';

        $points += self::WEIGHT_RENT / 2;
    }
}

So:

Within 10% → 20 points
Within 20% → 10 points
More than 20% → 0 points

This gives us a little tolerance without treating every price as equivalent.

6. Comparing Descriptions

For descriptions, I used PHP's built-in similar_text() rather than introducing another package.

similar_text(
    strtolower($a->description),
    strtolower($b->description),
    $sim
);

if ($sim >= 80) {
    $points += self::WEIGHT_DESCRIPTION;
} elseif ($sim >= 60) {
    $points += self::WEIGHT_DESCRIPTION / 2;
}

The thresholds are:

80%+ → 20 points
60–79% → 10 points
<60% → 0 points

This works reasonably well for short rental descriptions.

It is not intended to be a sophisticated natural-language similarity model.

And that's okay for this stage.

7. The Fingerprint Rule

A matching fingerprint is a strong signal:

Area
+
Landmark
+
Bedrooms
+
Property type

If those fields all match, I want the listing to be reviewed even if some other signals differ.

The final score is calculated like this:

$confidenceScore = round(min($points, 100), 2);

if ($details['fingerprint_match']) {
    $confidenceScore = max($confidenceScore, 90.0);
}

So a fingerprint match effectively creates a minimum score of 90.

That means the system classifies it as a very likely duplicate.

This is a deliberate product decision rather than a mathematical requirement.

Later, this should probably become configurable because two properties can theoretically share the same area, landmark, bedrooms and type while still being different properties.

8. Turning the Score Into a Match Level

I use an enum to map the score into a meaningful state:

public static function fromScore(float $score): self
{
    return match (true) {
        $score >= 90 => self::VERY_LIKELY,
        $score >= 70 => self::POSSIBLE,
        default      => self::UNIQUE,
    };
}

The resulting categories are:

Score	Level
90–100	Very likely
70–89	Possible
<70	Unique

The UI doesn't need to know how the score was calculated.

It simply displays the appropriate match level and the underlying explanation.

9. Persisting the Match Details

The score and explanation are stored on a duplicate_matches record.

For example:

property_id
matched_property_id
confidence_score
match_details
status

The match_details column is JSON.

That means I can store the complete scoring breakdown without creating a separate database column for every signal.

For example:

{
    "area_match": true,
    "landmark_match": true,
    "bedrooms_match": true,
    "rent_match": "within_10_percent",
    "rent_difference_percent": 4.2,
    "description_similarity": 87.4,
    "fingerprint_match": true
}

The reviewer UI can then display something like:

Very likely duplicate — 94

✓ Same area
✓ Same landmark
✓ Same bedrooms
✓ Rent within 10%
✓ Similar description
✓ Matching property fingerprint

That's much more useful than simply saying:

Duplicate confidence: 94%

10. Reviewer Decisions Must Survive Edits

There is another problem with running detection every time a property changes.

Suppose a reviewer sees:

Property A ↔ Property B

and decides:

These are different properties.

The reviewer rejects the match.

Then the agent edits the listing.

If detect() simply runs again and recreates the match, the reviewer gets the same warning again.

That's frustrating.

So duplicate matches have state:

pending
rejected
confirmed

When checking an existing match:

$existing = DuplicateMatch::query()
    ->where('property_id', $property->id)
    ->where('matched_property_id', $candidate->id)
    ->first();

if ($existing && $existing->status === 'rejected' && ! $rescan) {
    continue;
}

if ($existing && $existing->status === 'confirmed') {
    continue;
}

A rejected match stays rejected during normal edits.

A manual rescan can explicitly override that decision.

This makes the system behave more like a workflow rather than just a calculation.

11. Avoiding Timeline Noise

Duplicate detection can run frequently.

If every score recalculation creates a timeline event, the property history becomes noisy.

So I only log meaningful changes.

For example:

$scoreChanged = $existing
    && abs(
        (float) $existing->confidence_score
        - $score->confidenceScore
    ) >= 5;

A timeline event is created when:

A new match is detected
A manual rescan happens
The score changes significantly
A reviewer confirms/rejects a match

This keeps the audit trail useful.

12. Where Detection Runs

The detector runs after the property has been saved.

For example:

// PropertyCreator

$this->duplicateDetection->detect(
    $property,
    $user
);

And after an update:

// PropertyController@update

$this->duplicateDetection->detect(
    $property->fresh(),
    $user
);

This is also useful for bulk imports.

My .xlsx importer reuses the same property creation workflow.

That means imported properties automatically go through duplicate detection without implementing another version of the algorithm.

13. Testing the Detector

I didn't just test properties that I expected to be duplicates.

I created test spreadsheets containing both duplicates and controls.

Some examples:

Scenario	Score
Same fingerprint + cosmetic differences	100
Same area + different landmark + similar rent/description	80
Duplicate properties in one import	100
Same area but different size	25
Same area + bedrooms but different rent/description	40

The control cases are extremely important.

Without them, it's easy to keep increasing the number of signals until almost every property gets flagged.

A duplicate detector isn't useful if reviewers don't trust its results.

14. What I'd Fix Next

The current implementation works, but there are several areas I would improve.

Canonical Areas and Landmarks

Exact string matching creates problems:

Yaba

and:

Yaba, Lagos

are treated as different.

Similarly:

Opp. Yaba Tech

and:

Opposite Yaba Tech

are different strings.

A better approach would be a canonical area/landmark system with aliases.

For example:

Yaba
├── Yaba, Lagos
├── Yaba Lagos
└── Yaba Mainland

could all resolve to the same canonical identifier.

Case-Sensitive Candidate Queries

The scoring logic uses:

strcasecmp()

but the candidate query uses normal SQL equality.

That creates an inconsistency.

For example:

Yaba

and:

yaba

may score as a match but never become candidates in the first place.

With PostgreSQL, normalized columns or LOWER() expression indexes would make this more consistent.

Bedroom Type Casting

The database may return:

while another value might be:

"2"

If strict comparisons are used, those can behave differently.

Casting the model attribute is safer:

protected $casts = [
    'bedrooms' => 'integer',
];

Normalizing Match Pairs

Currently:

A → B

and:

B → A

can become separate records.

That means reviewers could potentially see the same duplicate pair twice.

A better approach is to normalize the IDs:

$firstId = min($property->id, $candidate->id);
$secondId = max($property->id, $candidate->id);

Then always store:

first_id
second_id

in a consistent order.

`similar_text()` Performance

PHP's similar_text() is convenient, but it isn't something I'd want to run against large amounts of text indefinitely.

For short rental descriptions, it's acceptable.

If descriptions become long or the candidate set grows significantly, I'd add a cheaper prefilter before running the similarity calculation.

The Fingerprint Floor

Currently:

if ($details['fingerprint_match']) {
    $confidenceScore = max($confidenceScore, 90);
}

This means matching identity fields can result in a duplicate score of 90 even when the rent is very different.

Sometimes that's correct.

Sometimes it isn't.

I'd eventually make the fingerprint floor configurable so product/operations can tune the behavior based on real reviewer decisions.

15. Why I Didn't Start With Machine Learning

There are three main reasons.

1. There wasn't enough training data

A new marketplace doesn't have thousands of confirmed duplicate/non-duplicate examples.

Without good labelled data, an ML model isn't automatically going to solve the problem.

2. Reviewers need explanations

If a reviewer asks:

"Why did you flag these two properties?"

I can answer:

"Same area, same landmark, same bedrooms, rent is 4.2% apart, and the descriptions are 87% similar."

That's actionable.

A black-box prediction isn't as useful for an operational workflow.

3. The weights are easy to change

The scoring weights are centralized:

private const WEIGHT_AREA = 25;
private const WEIGHT_LANDMARK = 20;
private const WEIGHT_BEDROOMS = 15;
private const WEIGHT_RENT = 20;
private const WEIGHT_DESCRIPTION = 20;

If reviewer feedback shows that one signal is too aggressive, I can tune it without introducing a new model-training pipeline.

The Bigger Lesson

The interesting part of this project wasn't really the scoring formula.

It was the workflow around it.

A useful duplicate detection system needs to answer more than:

"Are these two properties similar?"

It also needs to answer:

Why were they flagged?
What happens when a reviewer disagrees?
Does that decision survive future edits?
Can the reviewer rescan?
Can the match be confirmed?
Can the listings eventually be merged?
Can we audit what happened?
Can the scoring rules be changed later?

The detection algorithm is only one part of the feature.

The review workflow is what makes the detection useful in production.

Takeaways

If you're building duplicate detection for a marketplace, especially in a market without clean addresses:

Don't put a unique constraint on something humans are supposed to review.
Narrow candidates in SQL, then perform detailed scoring in application code.
Group your orWhere clauses carefully.
Store the explanation, not just the score.
Treat reviewer decisions as persistent state.
Test controls, not only the duplicates you want to catch.
Start with deterministic rules you can explain.
Use real reviewer decisions to improve the rules over time.

You don't always need machine learning to build useful marketplace intelligence.

Sometimes the best first version is a simple system that understands the signals your market actually has, produces a result people can explain, and gives humans the final say.

Difference between session and cookies in php

Sun, 20 Sep 2026 07:36:12 +0000

Today, we're going to discuss about two common things, that are Session and Cookies, which are used in the website to keep track of the information provided by the users, but for different purposes. A lot of beginners are confused about their characteristics, functionalities, and differences. In this study blog, we'll explore both of them in a more comprehensive way.

Introduction to Session and Cookies #

Session

Session is used to store information across the multiple pages of a website momentarily on the server-side files. It's useful when the website needs to track who is the current user across multiple pages of the same website. Let's look at the example:
1. A user is using a POST method to send a request to the server for logging in the website.
2. The information provided is sent to the server for validation via HTTP context.
3. However, the HTTP context doesn't maintain the state of a user. As a result, the server is able to validate the current user at the moment only when the request is sent. The other pages are not informed about who is the current user.
4. To overcome this limitation, the server will generate a unique session ID for that particular user and sent back to be stored in the browser in form of Cookie.
5. Whenever the user navigates across different pages, as long as the user is showing the consistent and valid session ID, different pages may recognize the same user.
6. Finally, a session will end and the cookie is deleted (if expiration date is not set) when a user log out or the application is shut down.
Cookies

Cookies is used to remember the user information such as browsing history, user preferences and login credentials on the client-site computer. It can only store maximum of 4KB data in the browser. The server will forget everything about the user such as his/her credentials and activities after the connection breaks. Hence, Cookies are very useful when you want a browser to "remember" the user. Let's look at the example:
1. A user, called "Alex" has chosen Keep me signed in and logged in to a website, his login credentials are stored in a Cookies and the server creates a session ID for him and sent back to the browser.
2. While navigating across multiple pages of the website, he's able to use his unique session ID to verify he's the current user.
3. After a few moment, he feels tired and close the browser.
4. When he comes back again and open the website, the browser will send a request to the server to get the web page, the Cookies belongings to that page will be added to the request via HTTP headers.
5. Since Cookies remembers his login credentials, it'll check the informtion against the server, and thus log in "Alex" automatically.
6. The lifetime of Cookies can be set and it's deleted when its lifetime has passed..
Note Since Cookies are stored on client-site computer, it can only be accessed by the user that initially created it. Other user cannot see it.

Now, we've some basic understanding on what is Session and Cookies. Let's go through their differences.

Difference between Session and Cookies #

Although both are used to track the information provided by the users, they still have some distinct differences. Let's see one by one:

Storage Location #

Session
A Session is stored as server-site files temporarily on the server. It'll be deleted when the application is shut down or the user logged out.
Cookies
A Cookies is stored as a client-site files on the user's computer. It'll be deleted when the expiration date has reached.

Security #

Session
A Session is more secure compare to a Cookies because it's on server-site and cannot be tampered easily. Besides, the data in a Session is encrypted and converted to binary form in the server.
Cookies
A Cookies is less secure because it's stored in the form of string text file on the client's computer. Whenever an unauthorized user get access to the system, he can alter the data easily.
Caution When you choose "Keep me logged in", if someone has stolen the unique identifier in the cookies, it's called cookie stealing and now they can access your account. Always be aware of this option!

Lifetime #

Session
A Session will be deleted once the user logs out or the application is shut down.
Cookies
A Cookies is deleted when the user specified expiration date has passed.

Stored Data Type #

Session
A Session stores the any type of value or the data type of an Object.
Cookies
A Cookies can only stores data in "string" type only.

Purpose of Usage #

Session
A Session is used to track an user's activity over a period of time. It's used to store the specific information of a user which should be consistent across multiple pages of a website. The example can be login status, user preferences, and shopping cart. When a user logs in the website, a session is generated in the server-site and the unique session ID is generated and stored in the user's devices as a cookie.
Cookies
A Cookies are used to store user's information in their computer or mobile device to "remember" their information such as tracking login information, user behavior and storing user preferences. When the next time they visit the same website, the browser'll send the Cookies along with the request to get the web page which compromises of more personalized and desired data for that particular user.

The Conclusion #

In this study blog, we've learned what's Session and Cookies, what are their differences in term of storage location, security, lifetime, stored data type, and purpose of usage. Bear in mind, both of them have their own pros and cons, but Session is more secure compared to Cookies. Hence, you should choose which one to use according to your own condition.

The Reference #

You may go through this reference for more information:

What's Session and Cookies: https://docs.oracle.com/en/middleware/webcenter/sites/12.2.1.3/wbcsd/sessions-and-cookies1.html#GUID-F8F240F3-E769-4B8C-8B7C-3886010D27BE

A Complete Guide to Install XAMPP, Configure Apache & MySQL Services, and Deploy WordPress Using Pow

Wed, 09 Sep 2026 10:21:11 +0000

Setting up a reliable local web development environment is one of the first steps for anyone working with WordPress, PHP, MySQL, or Apache. While XAMPP makes this process easier by bundling the required components into a single package, configuring the environment properly, especially through the command line, can still be challenging.

Many online tutorials focus only on the graphical interface and often skip essential configuration steps, troubleshooting techniques, or service management. As a result, beginners frequently encounter issues with Apache, MySQL, PHP compatibility, phpMyAdmin, or WordPress installation.

To address these challenges, I created a comprehensive guide that demonstrates how to install, configure, and manage an entire XAMPP and WordPress development environment using Windows PowerShell.

Whether you're a student learning web technologies, an educator preparing laboratory sessions, or a developer looking for a repeatable deployment process, this guide provides a structured approach from start to finish.

Why This Guide?

A properly configured local development environment saves hours of troubleshooting and creates a consistent workflow for development, testing, and learning.

Instead of relying solely on mouse clicks, this guide introduces a command-driven approach that helps users understand what happens behind the scenes while also making the installation process easier to reproduce across multiple machines.

The guide follows a complete workflow covering installation, service management, WordPress deployment, version upgrades, and troubleshooting.

What You'll Learn

The guide covers every major step required to build a local WordPress development environment.

1. XAMPP Installation

Learn how to install XAMPP using PowerShell commands, verify the installation, and safely uninstall and reinstall it when necessary.

Topics include:

Downloading XAMPP
Silent installation
Installation verification
Troubleshooting incomplete installations
Safe uninstallation

2. Apache Service Configuration

Apache is configured as a Windows Service, allowing it to be managed directly through PowerShell.

You'll learn how to:

Install Apache as a service
Verify service status
Start and stop Apache
Manage services efficiently
Troubleshoot service-related issues

3. MySQL Service Installation

Database configuration is an essential part of every WordPress deployment.

This section explains how to:

Install MySQL as a Windows Service
Verify successful installation
Start and stop the service
Prepare the database environment for WordPress

4. WordPress Deployment on XAMPP

One of the largest sections of the guide walks through deploying WordPress on a local server.

Topics include:

Creating WordPress databases
Configuring users and permissions
Downloading WordPress
Extracting and organizing files
Running the installation
Configuring the initial website
Accessing the WordPress dashboard

5. Upgrading PHP

Modern WordPress versions require newer PHP releases.

The guide explains how to safely:

Replace outdated PHP versions
Configure php.ini
Enable required PHP extensions
Update Apache configuration
Verify the installation

6. Upgrading phpMyAdmin

Many bundled XAMPP installations include older versions of phpMyAdmin.

The guide demonstrates:

Installing the latest release
Preserving existing configurations
Migrating settings safely
Verifying successful upgrades

7. Daily Service Management

Instead of opening the XAMPP Control Panel every time, the guide shows how to manage services directly from PowerShell.

This includes:

Starting Apache
Starting MySQL
Opening WordPress
Accessing phpMyAdmin
Stopping services after development

Why Use PowerShell Instead of Only the XAMPP Control Panel?

Learning to manage services through PowerShell provides several long-term advantages.

Faster setup
Easier automation
Better troubleshooting
Repeatable deployments
Improved understanding of Windows service management
Practical DevOps and system administration skills

These skills become increasingly valuable when working with larger development environments or automating deployments.

Who Should Read This Guide?

This guide is suitable for:

Web Developers
WordPress Developers
PHP Developers
Computer Science Students
Information Technology Students
Software Engineering Undergraduates
Lecturers and Instructors
System Administrators
Beginners learning local web development

It is especially useful in academic environments where students need to deploy multiple local development environments using consistent procedures.

GitHub Repository

The complete guide and supporting resources are available on GitHub.

GitHub Repository:

XAMPP-WordPress-PowerShell-Guide

If you find this resource useful, consider giving the repository a star. It helps increase visibility and encourages further improvements.

Also Published On

This article is also available on the following platforms:

LinkedIn: Read on LinkedIn
Medium: Read on Medium
AWS: Read on AWS
DEV Community: Read on DEV Community

Acknowledgements

I would like to express my sincere gratitude to Mr. Madusanka Mithrananda for his invaluable guidance, encouragement, and continuous support throughout the development of this guide and the article. His expertise, constructive feedback, and mentorship were instrumental in shaping this work and deepening my understanding of XAMPP, PowerShell, and WordPress deployment.

I truly appreciate his dedication to teaching, willingness to share knowledge, and the encouragement provided throughout this journey. His guidance has been an invaluable part of the successful completion of this guide.

Final Thoughts

Documentation is one of the most valuable yet overlooked contributions to the developer community. A clear, repeatable guide can save countless hours for students, developers, and educators trying to build reliable development environments.

This project was created with the goal of simplifying the setup process while encouraging developers to understand the underlying configuration instead of simply following GUI-based installation steps.

I hope it serves as a practical reference for anyone working with XAMPP, Apache, MySQL, PHP, PowerShell, and WordPress.

If you have suggestions, discover improvements, or would like to contribute, feel free to open an issue or submit a pull request on GitHub.

Happy coding!

Building a Real-Time Payment Gateway Integration with PHP, PayHere, ngrok, and MySQL

Wed, 09 Sep 2026 09:49:02 +0000

Recently, I built a complete real-time payment gateway integration using PHP, PayHere Sandbox, ngrok, and MySQL to simulate and test online payments in a local development environment.

This project covered:

Secure PayHere checkout integration
Real-time payment callback handling through ngrok
Transaction logging and MySQL database storage
Email notifications using PHPMailer
PDF receipt generation using mPDF

One of the most interesting parts of the project was using ngrok to expose localhost securely, allowing PayHere to communicate with local callback URLs such as notify_url, return_url, and cancel_url.

The project structure was designed to keep the workflow clean and modular, with separate files for checkout processing, notifications, verification, configuration, and database handling.

This implementation was a great hands-on experience in understanding how real-world payment systems work behind the scenes, from hash generation and callback verification to preventing duplicate transactions and securely handling payment confirmations.

Repository

GitHub Repository: https://github.com/NithilaLD/Building-a-Real-Time-Payment-Gateway-Integration-with-PHP-PayHere-ngrok-and-MySQL/

The repository includes the complete project resources, including the full implementation guide in PDF format, source code files for the payment gateway integration, and database setup scripts required to configure and run the application locally.

Tech Stack

Also Published On

This article is also available on the following platforms:

LinkedIn: Read on LinkedIn
Medium: Read on Medium
AWS: Read on AWS
DEV Community: Read on DEV Community

From a Commodore 64 to AI Agents: Istvan Dobrentei's Journey Through Software Development

Wed, 26 Aug 2026 01:28:04 +0000

From a Commodore 64 to AI Agents: Istvan Dobrentei's Journey Through Software Development

From a black-and-white TV and BASIC programming to PHP, cloud migration, DevOps, and today's world of AI agents and LLMs.

Meet Istvan Dobrentei

Some programming journeys begin with a computer science degree.

Others begin with a job.

Istvan Dobrentei's started with a Commodore 64 connected to a small black-and-white television.

At around 10 years old, Istvan encountered something that felt almost magical: a machine communicating with him through a TV screen.

The messages weren't exactly encouraging.

They included things like:

Syntax error

and

Type mismatch error

He didn't understand them yet.

But he was fascinated.

That curiosity eventually led him from BASIC to Turbo Pascal, C, Delphi, PHP, JavaScript and Java, and ultimately into a long career as a software engineer.

His first computer-related job came in 2001, working in a library where he built a PHP application that made publications searchable online.

In many ways, his journey into software development started with books.

Since then, his career has taken him through real-world business systems, legacy applications, cloud migration, DevOps, and modern web development.

Today, he is also exploring AI, LLMs and agentic architecture, alongside his background as a Zend-certified full-stack PHP developer and Microsoft- and AWS-certified engineer.

But technology is only one part of Istvan's story.

His journey has also been shaped by continuous learning, ethical decisions, difficult experiences, resilience, and the realization that good software is about much more than simply making code work.

In this Developer Story, Istvan takes us from his first Commodore 64 to the modern world of AI and shares the lessons he has learned along the way.

Istvan's Story

It Started With a Commodore 64

When I was around 10 years old, I got my first computer: a Commodore 64.

At that time, it was something truly special.

Have you ever heard about the COCOM list?

Technology behind the Iron Curtain was very limited.

There was no monitor, so we had to connect the machine to a TV and manually adjust the frequency just to see the command prompt on the screen.

Back then, even having a color TV was a big deal.

I remember that I only had a small black-and-white TV called Junoszty.

In our country, there weren't many opportunities to learn English during that period.

Russian was mandatory in school, and I could choose only one additional language: German.

So when I saw the very first message appear on the black-and-white TV screen, I felt like I was on the moon.

The machine was communicating with me!

The messages were things like:

Syntax error

and

Type mismatch error

At that time, I had no idea what they meant, but I was fascinated.

Today, of course, I understand them well, but back then it felt almost magical.

Imagining a Worldwide Computer Network

I also clearly remember reading an article about computer networks in a magazine around 1992.

They wrote about CompuServe, and I imagined what a worldwide computer network could look like.

Today, of course, we know it as the World Wide Web.

My friends and I spent many hours playing games on that machine.

But eventually, programming became more interesting than simply using the computer.

One day, a friend gave me a book about the BASIC programming language.

I was probably 12 or 13 years old, and that was when I started learning programming by myself.

Later, in school, I chose computer science subjects to learn more.

We started with BASIC, then moved on to:

Turbo Pascal
C
Delphi

Around 2000, I learned PHP and JavaScript, and later Java.

Learning the Fundamentals

At the very beginning, in the classroom environment, I learned from mathematics teachers and solved basic mathematical and programming problems.

I also had a book full of beginner programming exercises.

Learning the fundamentals was very important.

I created many side projects that helped solve different kinds of problems.

For example, I developed an application that helped teachers organize class schedules and subject timelines for different classrooms.

Those projects gave me something that books alone couldn't provide:

practice.

You learn something differently when you actually have to make it work.

Interestingly, my first job was not related to computers.

I first worked as a book sales agent, and later I worked in a library.

That became my first computer-related job in 2001.

There, I learned PHP and created my first real application.

It helped organize different kinds of publications and made them searchable through an online interface.

Looking back, there is something quite fitting about this.

My journey into software development started with books.

Those early experiences eventually led me into professional web development and a career that would span many different technologies.

What Years of Experience Changed

It is really interesting because today I see myself in a different way.

After many years of experience, I see things very differently than I did when I was younger.

I have seen many kinds of code across many different domains and businesses of various sizes.

I have seen insightful and highly successful companies, but also shrinking businesses, along with the codebases behind those business models.

One surprising realization was that the best-designed and most well-organized code wasn't always the one that generated huge profits or became the most successful.

That was a key moment for me.

It taught me that business success depends on many factors beyond technology alone.

At the same time, I realized that good architecture and clean code are essential for long-term success.

Good code improves:

maintainability
scalability
teamwork
long-term sustainability

In many cases, poorly designed systems eventually become difficult to maintain and slow down innovation.

So I've learned that software engineering requires a balance.

Technology matters, but technology alone does not determine business success.

The Challenge of Working With Real Businesses

One of the biggest challenges in my developer journey was working as an independent contractor for SMEs.

I saw many interesting business ideas and situations from a business perspective.

However, I always stayed committed to ethical and legal principles.

Whenever I was asked to do something that was against the law or not ethical, I said no.

For me, that is an important part of being a professional.

Developers can have access to sensitive systems, information, business processes, and data.

Technical ability comes with responsibility.

Sometimes doing the right thing means refusing to do something.

Migrating a Legacy Webshop to the Cloud

Another major challenge was migrating a live legacy webshop to a cloud environment.

At that time, cloud technologies were a completely new area for me.

I had to quickly learn many different concepts and technologies.

To overcome the challenge, I invested a lot of time in learning, earned relevant certifications, and continuously improved my knowledge step by step.

In the end, the migration was successful.

The experience taught me the importance of:

adaptability
continuous learning
persistence

Technology doesn't wait for you to become comfortable.

Sometimes you have to learn something new because the project demands it.

There Is No Single Technology That Defines a Developer

I don't think there is a single technology that I could highlight as being responsible for my growth.

In the IT industry, continuous learning and self-learning are what really matter.

New solutions, tools, and resources appear every month, especially in today's world.

One thing is certain:

Continuous learning and adapting to change are essential.

Instead of focusing only on specific technologies, I would highlight:

critical thinking
curiosity
the ability to learn new things every day
adapting to change

Technologies will come and go.

The ability to learn remains.

The Job That Taught Me a Difficult Lesson

I remember a sad story, although today I can laugh about it.

At the time, however, it was a very difficult experience.

Once, I applied for a job where my task was to create an Android application to handle one of the company's logistics business functions.

It was an experimental project.

The company worked in a team environment without any version control and without applying object-oriented principles.

That really shocked me.

One day, the CEO asked for my opinion about their system.

I spent the weekend preparing a detailed and honest presentation and presented it to the team.

The next day, I was unemployed.

I did not criticize the system personally.

I only highlighted the main issues and shared what I had learned over the years.

It was a difficult experience.

But it taught me something important.

Life can sometimes be difficult and unfair.

Not every situation will reward honesty immediately.

But persistence and hard work eventually pay off.

Never give up.

Learning to Think Like a Developer

At the beginning of my learning journey, even solving simple tasks programmatically was a challenge.

Learning how to think like a developer and how to write code was not easy at first.

I believe software development is a step-by-step journey.

One of the most important lessons I learned is to try solving problems by yourself instead of always looking for shortcuts.

Practice is essential.

The more you build, experiment, and learn from mistakes, the more you improve over time.

You don't become a better developer simply by reading about programming.

You become better by actually doing it.

Nobody Is Perfect

Another important lesson is that nobody is perfect, and growth is a continuous process.

Mistakes are a natural part of learning.

The real question is whether you are able to reflect on them, adapt, and move forward.

This is especially important in technology because there is always something new to learn.

You will make mistakes.

You will sometimes choose the wrong technology.

You will sometimes write code that you later want to rewrite.

That's normal.

What matters is what you learn from the experience.

Resilience Matters

I also learned the importance of resilience.

Resilience is the ability to recharge yourself after challenges and keep going even when things become difficult.

Software development can be frustrating.

Projects can fail.

Jobs can end unexpectedly.

Technologies can change.

You can spend days solving a problem that seemed like it should take an hour.

The ability to recover and continue is therefore just as important as technical knowledge.

Learn From Other People

Having mentors and being open to feedback is extremely valuable.

Nobody can know everything or be an expert in every area.

It is essential to accept advice and learn from others.

Doing so can accelerate both personal and professional growth much faster than trying to figure everything out alone.

Don't hesitate to ask questions.

Don't be afraid to admit that you don't understand something.

Learning from other people is not a weakness.

It is one of the fastest ways to grow.

From PHP to Cloud and AI

My technology journey has continued to evolve.

PHP and web development remain an important part of my background, but my interests have expanded into cloud, DevOps, AI, and modern development tools.

I've earned certifications including:

PHP Zend Engineer
Microsoft Azure Fundamentals
Microsoft Azure Developer Associate
Microsoft DevOps Engineer Expert
AWS Certified AI Practitioner

Today, I'm particularly interested in LLMs, AI, cloud technologies, and AI agents.

The interesting thing about technology is that the learning never really stops.

The Commodore 64 I used as a child could not have prepared me for today's AI systems.

But the curiosity that made me want to understand that first computer is still useful.

The tools changed.

The curiosity didn't.

Advice for Developers Starting Today

As I mentioned earlier, in our rapidly changing world, the most important thing is to keep learning new things, stay curious, and never give up.

Hard work pays off in the long term.

Teamwork is also very important because nobody can know everything or be an expert in every area.

It is essential to truly understand what you are doing.

Don't just copy and paste code.

Understand why it works.

Understand why a feature works.

And understand why a feature may not work.

If you have doubts or don't understand something, ask for help.

There is nothing wrong with asking questions.

In fact, asking the right question can sometimes teach you more than finding the answer yourself.

My Experience With CoderLegion

It was a surprise for me when I was first invited to create publications.

It is an honor to share my thoughts with the community through a platform like CoderLegion.

It is also great to see the active community and the engagement behind the platform.

I have been able to read many interesting and up-to-date articles from talented people all around the world.

This gives me motivation to keep moving forward and continue learning.

Thank you for the opportunity, and I wish continued success to both the community and CoderLegion.

Looking Back

When I think about my journey, the contrast is quite remarkable.

I started with a Commodore 64 connected to a black-and-white television.

I learned BASIC from a book.

Then came Turbo Pascal, C, Delphi, PHP, JavaScript, and Java.

I worked in a library and built a searchable publication system.

I worked with real businesses and legacy systems.

I learned cloud technologies when they were new to me.

I earned certifications and continued developing my skills.

And today, I'm exploring AI, LLMs, cloud technologies, and AI agents.

The technology has changed dramatically.

But the fundamental lesson has remained the same:

Stay curious. Keep learning. Never give up.

About Istvan Dobrentei

Istvan Dobrentei is a Software Engineer and Zend-certified full-stack PHP developer based in Hungary.

His technical background includes PHP, JavaScript, Python, Docker, MySQL, Ansible, and GitHub, alongside extensive experience with Microsoft Azure and DevOps.

He holds certifications including PHP Zend Engineer, AWS Certified AI Practitioner, Microsoft Azure Developer Associate, and Microsoft DevOps Engineer Expert.

Today, Istvan is exploring LLMs, AI, cloud technologies, AI agents, and agentic architecture, continuing a technology journey that began with a Commodore 64 when he was a child.

You can learn more about Istvan and his work on his website and CoderLegion profile.

A Final Thought

Istvan's journey shows how dramatically a developer's world can change.

A child connecting a Commodore 64 to a black-and-white television could hardly have imagined today's cloud platforms, AI agents, and large language models.

But perhaps the most important skill was already there.

Curiosity.

The desire to understand how something works.

The willingness to learn.

The courage to ask questions.

And the resilience to keep going when things don't work out.

Technologies will continue to change.

Programming languages will evolve.

New AI systems will appear.

But the developers who continue to learn, adapt, and stay curious will always have somewhere to go next.

The technology changes. The learning never stops.

This Developer Story is part of CoderLegion's Developer Stories series, where we share the real journeys, experiences, challenges, and lessons of developers from our community.

Ranking New Papers By Meaning Instead Of Keywords, In One PHP App

Sun, 23 Aug 2026 22:05:46 +0000

Most of us have built some version of a scheduled job that watches a feed and mails out a summary, and it almost never fails on the plumbing. It fails on relevance, and this is a writeup of a small PHP and SQLite project that puts a model scoring step where the keyword filter usually goes.

Why Keyword Alerts Keep Missing The Right Paper

Every major index offers alerts, and they all match on words. That is the whole problem. A paper that applies your exact method in a neighboring field will share none of your keywords, so it never reaches you. A paper that happens to use your words while solving an unrelated problem arrives every single week.

Word overlap is a proxy for relevance, and it is a bad one the moment your work sits between two subfields. Any watcher you build on top of a keyword query inherits that ceiling no matter how good the rest of the code is.

The Shape Of The Pipeline

Literature Radar splits the job into four steps, and the split is the interesting part.

First, an interest profile. Not a keyword list, a short paragraph written the way you would describe your work to a colleague. Separately you define topic queries that tell the poller what to pull, so retrieval stays broad while ranking stays narrow.

Second, a scheduled poll against arXiv, PubMed, Crossref, bioRxiv and medRxiv, writing into one local SQLite file. Anything already seen is skipped, so the table doubles as the dedupe layer.

Third, the ranking pass. Your model reads each new title and abstract and scores it 0 to 10 against the profile, attaching a one line reason. This is where a paper about your method in another field can outscore a paper that matched your keywords exactly.

Fourth, the digest. One email on your schedule, best first, score and reason attached, nothing repeated across sends.

Choosing Where The Ranking Runs

The ranking backend is resolved in order: the Claude command line tool, the Codex command line tool, an Anthropic API key, then any OpenAI compatible endpoint, which covers OpenAI, OpenRouter, and local servers like Ollama or LM Studio.

That order matters for cost. If you already pay for a Claude or ChatGPT subscription, the CLI path means the ranking step adds no per token cost at all, which is what makes a daily job over a few hundred abstracts practical for one person. Falling back to a local model through an OpenAI compatible endpoint keeps abstracts on your own machine entirely.

The whole thing is one PHP app plus one SQLite file, driven by a single cron entry that decides internally whether a poll, a rank, or a digest is due:

0 */2 * * * php /path/to/Literature-Radar/cli/cron.php

Each step also runs standalone, which is what you want while tuning the profile.

What Transfers To Your Own Watcher

Three things generalize past papers. Keep retrieval broad and put the judgment in a separate ranking pass, because a narrow query loses items you can never recover later. Store the reason next to the score, since a ranked list with no explanation gives you nothing to tune against. And make the scoring backend swappable from day one, because the model you start on will not be the one you finish on.

It is MIT licensed with no account and no service in the middle, so the abstracts go to whichever model you picked and nowhere else.

One PHP App and One SQLite File: A Self Hosted Workflow Engine

Fri, 14 Aug 2026 16:23:47 +0000

Most of us here have written the same glue script more than once, the one that catches a form submission and pushes it somewhere else, then quietly rots in a cron job nobody documented. This is a look at an open source engine that gives that glue a proper home on your own server, written for anyone who has priced a hosted automation tool and done the math.

What It Actually Is

Workflow Chain Engine is a visual workflow automation engine you host yourself. You draw a flow in the browser, call an API, branch on the answer, loop over a list, and end in success or fail. The whole system is one small PHP application with a single SQLite file. No framework, no build step, no dependency install, and the editor library ships inside the project, so nothing is loaded from a CDN at runtime.

That constraint is the interesting part. It means the tool is at home on a three dollar shared host, a VPS, or a Docker container, which matters when the process you are automating is worth ten dollars a month rather than two hundred.

The Parts That Matter in Practice

Six node types cover the logic you need: calling out, branching, looping, and terminating in a success or fail state. Variables carry data between steps, so the response from one API call is available to the next node without writing any glue of your own to move it there.

Triggers come in four flavors: a webhook, a schedule, a call from your own code, or a button someone clicks. That last one is underrated. A lot of internal automation is really a task somebody runs by hand at an unpredictable time, and handing that person a button beats handing them a runbook.

The Run Log Is the Feature

Every run leaves a step by step log you can actually read. That sounds mundane right up until you have debugged a hosted automation whose entire error report was the phrase workflow failed. Knowing which node fired, what it received, and what it returned is the difference between a five minute fix and a lost afternoon.

Loop protection is built in as well, which is the other thing you want in place before you point a webhook at something capable of calling itself.

Worth a Look If

You are already self hosting the database and the object storage but still renting the glue. The code is MIT licensed and on GitHub, so the cost of finding out is one afternoon.

Turn-Based Multiplayer Without a Websocket Server

Fri, 14 Aug 2026 00:02:08 +0000

Most multiplayer tutorials on here jump straight to websockets, and for a real-time shooter that is the right call. For a turn-based game it is usually more machinery than the problem needs, so here is the plain HTTP version for anyone who has been putting multiplayer off.

The Three Problems A Turn-Based Game Actually Has

Every turn-based multiplayer game needs the same three things: players have to find each other, friends have to be able to play on purpose, and every player has to see every move in the same order. None of those three require a persistent connection. A queue can be polled, a join code is a lookup, and move ordering is what a database does for a living.

The usual reason people reach for websockets is push. In a turn-based game the push is worth very little, because a human is going to take several seconds to decide anyway. A two second poll while it is the opponent's turn feels identical to the player and costs you nothing operationally.

What The Server Should Not Know

The design decision that saves the most work is keeping game rules out of the server. Treat a move as an action with a type and a few opaque data fields, and let your clients decide what the fields mean. Chess notation, a card play, a dice roll, a word submission, a chat line, a surrender flag, they are all the same shape to the server.

Once the server holds no rules, one deployment serves every game you write. You do not stand up new infrastructure for each project, and a rules change never means a server deploy.

A Working Reference

If you want to read a small implementation rather than a diagram, AbraTabia Game Server is one PHP application with a single SQLite file, five HTTPS endpoints, MIT licensed. Queue entries and finished matches expire on their own, and an admin view shows the live queue, active matches, and the full action log for each match.

It runs on shared hosting, a VPS, a container, or a laptop during development, which is the real point: for turn-based games the infrastructure bill for multiplayer can be zero.

Where This Stops Working

Be honest about the boundary. Anything with continuous state, physics, or sub-second reaction time wants a real-time transport and probably an authoritative simulation. The polling model covers turn-based, asynchronous, and most board and card game designs, and it stops being a good idea the moment your game has a frame rate that both players share.

Amazon Runs Agents. Mercado Libre Runs on Manual Spanish Replies.

Mon, 03 Aug 2026 08:26:39 +0000

The Amazon seller's morning is already automated. An ads agent adjusted bids overnight, added negative keywords at 2 AM, and topped up the budget when CPC spiked. A product-selection agent scanned thousands of reviews and flagged a sub-category with weak competition. Customer service is running at 90% auto-reply. The official assistant — now on its third generation — is quietly clearing dead stock from the warehouse.

Meanwhile, at a Mercado Libre operation in São Paulo, someone is manually typing "Olá, muito obrigado pela sua compra" into an internal message box at 11 PM, because the 24-hour reply deadline is tied to store rating, and store rating is tied to traffic. The restock forecast lives in an Excel sheet. The translation software produces Spanish that reads like translated software.

This is the Mercado Libre Agent Gap: the largest e-commerce ecosystem in Latin America — 120 million annual buyers, 2.4 billion items sold in 2025 — has no seller-agent ecosystem. Not a nascent one. Not a struggling one. Zero.

Two Daily Realities

Amazon's seller tooling has been through three full generations. The first was rule-based automation: if this happens, do that. The second added prediction: forecast demand, pre-adjust bids. The third is agentic: autonomous execution with objectives. Ad agents that reallocate budget when ROAS dips. Creative agents that generate ad imagery from text prompts and lift ROAS by 121% in some campaigns. Inventory agents that clear dead stock before storage fees eat margin.

The numbers from Amazon's official agent rollout are not subtle. Ads agents improved outcomes for 65% of advertisers, with CPM down 18% and CPA down 16%. The seller assistant's agentic auto-publish feature moved old listings up 12 organic ranking positions, lifted mobile conversion 14.3%, and cut returns 9%. This is not laboratory performance — this is production tooling at platform scale.

Mercado Libre sellers operate like it's 2015. Portuguese replies are typed by hand. Spanish replies are run through translation software and then patched up by whoever speaks the language best. Restock forecasts are Excel formulas. When a stockout hits — and it hits often, because Brazil customs clearance is measured in months, not days — the listing weight resets to zero. Years of accumulated ranking, reviews, and sales velocity evaporate.

The Three Walls

Why is there no agent ecosystem on Mercado Libre? Three walls.

The language wall. Spanish and Portuguese are not English with a dictionary swap. They are complete systems of search habits, slang, and complaint phrasing. A Peruvian buyer writes "me llegó chueco" — it arrived crooked — and no translation tool picks up the implicit defect claim. A Brazilian buyer searches "ventilador" when they want a fan and "circulador de ar" when they want an air circulator; a seller who translated "air circulator" literally loses the first search entirely. Customer service agents on Mercado Libre need to parse colloquial complaints, respond within platform time windows, and do it in two languages. That is a hard automation problem. It is also the entire game.

The data wall. Mercado Libre's platform data openness is low, and the third-party tool ecosystem reflects it. On the Amazon side, one analytics tool alone has 1.5 million users; entire companies are built on scraping, analyzing, and predicting Amazon listing performance. Mercado Libre's third-party ecosystem is a desert. Without data access, agents have nothing to train on and nothing to execute against.

The heavy model. The typical cross-border seller on Mercado Libre runs a local store, an overseas warehouse, a Full (Fulfillment by Mercado Libre) warehouse, and CBT multi-account operations simultaneously. That's four inventory pools, four pricing logics, and four reputation scores to manage. Amazon sellers mostly deal with one fulfillment mechanism. Mercado Libre sellers are running a logistics company, a customer service company, and a marketplace operation at the same time — by hand.

Six Gaps No Agent Has Filled

Walk through a Mercado Libre operation and the blank spaces are obvious.

1. Spanish/Portuguese intelligent customer service. The 24-hour reply rule is a traffic lever, not a compliance checkbox. Reply speed feeds store rating, and rating feeds search placement. A five-person team often has two people permanently stuck on internal messages — the platform's chat — while product questions, order inquiries, and return requests pile up. The Q&A standard is a 10-minute response window. No seller meets it consistently. Nobody even comes close.

2. Listing localization. Around 99% of cross-border sellers "translate" listings instead of "localizing" them. The ventilador/circulador example is not an edge case; it's the norm. Localization means understanding that Spanish speakers in Mexico search differently than Spanish speakers in Argentina, that Brazilian Portuguese has its own e-commerce vocabulary, and that sizing, color names, and product descriptors are culturally loaded. An agent that localizes listings — not just translates them — would be an instant ranking lever.

3. Mercado Ads agent. Amazon's ad agents are on generation three. Mercado Libre sellers are monitoring ACOS manually, in spreadsheets, with no automated bid adjustment and no negative-keyword engine. The gap between "the platform will sell ads to anyone" and "nobody has built a tool to manage those ads" is one of the strangest open opportunities in e-commerce.

4. Full/overseas warehouse restock forecast. Brazil customs clearance is counted in months. Restock lead times run 60 to 90 days. The restock formula is simple — (daily sales × days in transit) + safety stock — but the execution is brutal. Inventory below 15 days of daily sales drops listing weight by 30%. Stockout resets it to zero. Every forecast error is either stranded inventory or a destroyed listing.

5. Store reputation maintenance. Reputación is the traffic master switch on Mercado Libre. Negative reviews and late case resolutions deduct points; points determine visibility; visibility determines sales. The order defect rate ceiling is 0.8%. Self-fulfillment on-time rate must stay at 96%. One 1-star review can take daily sales from 40-plus units to single digits. Sellers are managing reputation with manual review monitoring and prayer.

6. Multi-account data dashboard. Local store, CBT store, overseas warehouse, Full warehouse. Four isolated islands. No unified view of inventory, orders, or performance. An Amazon seller can see their entire operation in one dashboard; a Mercado Libre seller is tabbing between four.

The Market Behind the Vacuum

The opportunity is not hypothetical. Mercado Libre's 2025 full-year results: net revenue of $28.9 billion, up 39%; GMV of $65 billion, up 26%; 2.4 billion items sold; 120 million annual buyers. This is a platform the size of Amazon's international business, with a fraction of the tooling.

Chinese sellers hold less than 1% of the Brazilian market and a negligible share in Colombia. The category is a blue ocean. Meanwhile, 80% of Mercado Libre sellers are SMBs — small operators who cannot build internal tooling and will pay for software that moves the needle. The willingness to pay is there. The product is not.

Mercado Libre's official AI efforts are real but deliberately limited. The Seller Assistant, launched in March 2026, grew daily active users 40% month-over-month and now touches roughly 20% of GMV. Mercado Pago's AI resolves 87% of customer interactions without human involvement. The official arbitration AI handles 10% of customer-service disputes — the equivalent of 9,000 human agents making $450 million in decisions annually.

But all of this is platform-side. The official tools offer recommendations and content, not seller-side autonomous agents. Third-party tools exist — customer-service agents at $39–199 per month, ERPs covering 30+ platforms with over a million sellers — but they solve single-point problems. Nobody has built the integrated agent layer.

Here is the gap within the gap. About 90% of Latin American transactions happen — or at least are negotiated — on WhatsApp. Buyers message sellers there. Sellers confirm orders there. Disputes get hashed out there. But WhatsApp is completely fragmented from the platform ecosystem.

A seller today manages the platform internal message system, WhatsApp conversations, and Spanish/Portuguese language requirements as three separate workloads. The 8-business-hour internal message deadline, the 10-minute Q&A standard, and the WhatsApp response expectation are three different clocks running simultaneously.

A three-in-one agent — internal message + WhatsApp + bilingual Spanish/Portuguese — does not exist. It is the single biggest white space in Latin American e-commerce tooling. The platform-side agents can't reach WhatsApp. The WhatsApp tools can't reach platform data. The translation tools can't handle either one with context. The seller is the only integration point, and the seller is a human being typing Portuguese at 11 PM.

What the First Real Agent Stack Looks Like

The first functional Mercado Libre agent stack will not be a single bot. It will be an operations layer that sits across all of it: order sync across local and CBT stores, warehouse consolidation logic that knows what is in the overseas warehouse versus the Full warehouse versus in transit, and restock forecasting that accounts for Brazil's month-scale customs timeline.

That same layer handles the three most expensive manual workloads: ads management with automated bid and budget adjustments, restock forecasting tied to real inventory positions, and a multi-account dashboard that finally connects the isolated islands.

The sellers who get there first will not just save labor. They will compound. Every hour not spent typing Portuguese replies is an hour spent on listing quality, on pricing, on the product-side work that actually moves rankings. Every stockout avoided is listing weight preserved. Every localized listing is a new search term won.

The tools for competing in Latin America already exist in the form of Chinese cross-border e-commerce software — mature, aggressive, battle-tested on Amazon. What they lack is the Latin America layer: the languages, the customs timelines, the WhatsApp integration, the Reputación logic.

Mercado Libre's sellers are still replying by hand in a market where 120 million buyers made 2.4 billion purchases last year. The agent gap is the biggest open category in Latin American e-commerce. It will not stay open long.

The Cost of Failing Closed: What Shipped Across Nine PHP Extensions

Mon, 27 Jul 2026 19:19:31 +0000

Making ExcelBook::save() atomic is easy to describe. Write the workbook to a temporary file, then rename it into place. A save that dies halfway leaves the original file untouched.

The obvious way to build that staged file is to ask LibXL for the finished archive as one buffer and write the buffer out. It works. It also costs 67.7 MB of peak RSS on a 3.3 MB workbook, and the PHP-side copy counts against memory_limit. The streaming writer php_excel used before the staging work costs 0.7 MB for the same file. That is roughly twenty times the workbook size in RAM, spent by a change whose whole purpose was safety.

That one arrived and was fixed inside the same release window, so no published version carries it. It is still a fair summary of the last two weeks. Nine of my PHP extensions released today. Between them they add one new method, one set of interfaces, and a few error constants. Everything else is a bug fixed, a value rejected, a limit enforced, or a cost paid back down.

The previous roundup ended on the claim that most of the work in these extensions is the unglamorous kind. This cycle is what comes after that claim, and it has a bill attached. Checking something on every row costs something on every row. Staging a write costs memory. Validating a wrapper at construction costs construction time. Most of the performance work below is repair rather than new optimization: finding where the safety checks got expensive, and making them cheap again.

php_excel 2.6.0: every save stages and renames

2.5.0 extended atomic save from stream wrappers to plain local paths, then restored the streaming writer underneath it. Local saves now stage through xlBookSave into an exclusively created sibling temp file and rename it into place, so the atomicity holds and the memory cost does not. Save time is unchanged. The staged file also carries the destination's existing permission bits, so replacing a 0600 workbook no longer widens it to 0644.

Atomicity on local paths changes three behaviours worth knowing before you upgrade. A symlink destination is replaced by a regular file instead of written through. An existing hard link is broken. Saving into a writable file inside a non-writable directory now fails instead of succeeding, because the rename needs the directory.

Typed writes stopped lying. An explicit data type that the value cannot satisfy is now rejected rather than silently stored as something else.

// 2.4.0: stored the string as text. 2.5.0: rejects, and names the cell it stopped at.
$sheet->write(0, 0, 'not a date', null, ExcelFormat::AS_DATE);

null still writes a blank cell under any data type, so bulk writeRow() and writeCol() calls over a typed column with gaps keep working.

2.6.0 is two lines on top of that, and one is breaking. ExcelFormat::borderDiagonalStyle() was wired to the diagonal direction rather than the line style it is named for. It now addresses the style, and the new ExcelFormat::borderDiagonal() gets and sets which diagonals are drawn. Code passing a BORDERDIAGONAL_* constant to the old method keeps running without error and quietly stops drawing its diagonal, so it is worth grepping for.

github.com/iliaal/php_excel

pdo_duckdb 0.5.0: the sandbox stopped charging by the row

The open_basedir sandbox re-latched itself once per row and compared the recorded basedir by hash. Under a long open_basedir that cost scaled with the string length, which is a strange thing for a per-row cost to depend on. It now re-latches once per fetched data chunk and compares by string.

A 400,000 row scan with a 223 character open_basedir went from 133 ns/row back to 51 ns/row. Bulk Appender::appendRow() went from 196 ns/row back to 96 ns/row.

The rest of the release is the sandbox itself getting harder to walk out of. DuckDB re-allowlists a non-empty temp_directory and any attached paths when external access is turned off, and those entries cannot be cleared afterwards, so the escalate sequence now clears temp, clears the sticky log_query_path and profiling_output writers, drops the path allowlists, and detaches out-of-basedir databases before flipping enable_external_access off and locking configuration. Re-narrowing open_basedir after that fails closed rather than leaving the wider policy in force.

One rendering bug is worth calling out because it is silent. A DECIMAL whose type has no integer digits rendered with a leading zero that DuckDB itself does not emit.

// DECIMAL(2,2): DuckDB renders .05, the driver rendered 0.05

That affected scalar cells since 0.4.1 and nested LIST, ARRAY, STRUCT, and MAP cells since the direct nested renderer landed. Prebuilt binaries now link DuckDB 1.5.5; a source build still works against the advertised 1.5.3 floor.

github.com/iliaal/pdo_duckdb

fast_uuid 0.6.0: a batch that reads the clock once

uuid_v7_batch() and uuid_v7_bin_batch() used to read the clock once per UUID. They now read it once per call, which is about 2.6x faster per UUID on aarch64. The v4 batch generators draw CSPRNG bytes for 64 UUIDs at a time instead of 16 bytes per UUID, worth another 6 to 8%.

$ids = uuid_v7_batch(100000);   // ~8 ms, all carrying the batch-start millisecond

The trade is stated in the release notes because it is observable: every UUID in one call carries the batch-start millisecond, so getDateTime() on the tail of a large batch can trail the wall clock by the batch duration. Values stay unique, sorted, and monotonic against the next single call.

The compat layer paid a cost in the other direction. Internal\ConstructionToken::Trusted used to skip the wrapper-class check, and it no longer does, so every compat wrapper validates its core on construction. That is one getVersion() call and a class-name comparison, and it makes construction about a third slower than 0.4.0: UuidFactory::fromBytes() drops from 1.81M to 1.21M ops/s on aarch64. I kept it. A wrapper that does not match its core is a bug that surfaces somewhere much less convenient.

0.6.0 also settled how far the compat layer follows ramsey/uuid. Every identity form now derives from toString(), as it does upstream, so getUrn(), getHex(), getInteger(), equals(), and compareTo() all follow a COMB codec's reshaped text rather than the network-order core. The one deliberate departure is GuidStringCodec, which reshapes the byte array only. Over 400 $guidFactory->uuid4() calls, ramsey/uuid 4.9.2 threw 190 times with "The byte string received does not contain a valid version" and emitted a wrong version nibble in the text 184 more times, leaving 26 clean. The same loop here returns 400 usable v4 GUIDs.

github.com/iliaal/fast_uuid

fastchart 1.7.0: limits, and one honest regression

Every documented resource and numeric limit is now enforced before valid chart state is replaced. Pie totals, graph-label aggregates, error-bar arrays, Venn sets, category labels, and scatter image-map strings used to validate after clearing, so a caught over-cap ValueError left you holding a wiped chart. Arc, Chord, and Network setNodes() and setLinks() throw on over-cap input instead of silently truncating it.

Two new INI settings bound memory that memory_limit never saw, because it lives outside the PHP allocator:

fastchart.max_render_pixels = 64M      ; PHP_INI_SYSTEM, bounds raster buffers
fastchart.max_image_cache_bytes = 64M  ; PHP_INI_SYSTEM, bounds retained decoded images

Caller-supplied SVG is now rejected above 65,536 elements, 262,144 attributes, or 256 nesting levels. renderToFile() accepts only local filesystem paths, because a stream wrapper cannot provide atomic replacement, and it preserves an existing destination's mode, revalidates open_basedir and staging identity at commit, and leaves the prior file under a recovery name when a post-install race prevents cleanup.

The performance line is mixed and I would rather write it down than round it off. Stock rolling indicators moved to linear-time extrema and statistics paths, and ordinary series are 2 to 33% faster. A stock series carrying a near-DBL_MAX outlier with a multi-thousand window costs about 4x the 1.6.0 setter time, because that series now goes through normalized sliding aggregates instead of an overflow-prone accumulator. Raster file output streams encoder bytes straight into the atomic destination, and in-memory raster output no longer keeps a second full-size pixel frame.

github.com/iliaal/fastchart

fastjson 0.7.0: ext/json parity, down to the error state

fastjson's promise is that you can swap it in for ext/json, and this release is mostly about the places where that wasn't quite true. fastjson_encode(), fastjson_file_encode(), and replacement encoding in fastjson_pointer_set() now publish the outer operation's final error state after a nested callback or destructor calls fastjson recursively. A decode of a string carrying both a backslash escape and invalid UTF-8 under JSON_INVALID_UTF8_IGNORE no longer rejects: "\/\xFFe" was reported as an unexpected control character and now decodes to /e, as json_decode() does.

fastjson_pointer_set() picked up three fixes that matter if you use it on documents you didn't write. It validates pointer syntax and traversal before serialising the replacement, so a malformed pointer no longer runs JsonSerializable callbacks first. It preserves untouched number lexemes byte for byte, so large integers, -0, and trailing-zero forms survive a set elsewhere in the document. And fastjson_pointer_get() now rejects a pointer whose traversed path is made ambiguous by duplicate object members rather than silently taking the first.

The performance work, measured against 0.6.0 on PHP 8.4 release builds, x86_64 unless the changelog notes aarch64:

fastjson_merge_patch(), 2,000-key merge: ~95% faster
Large clean-ASCII encode, 256 KiB to 1 MiB: 32 to 66% faster
Tolerant decode on clean input: 20 to 64% faster
Packed-array decode: ~22% faster
fastjson_pointer_set(): 42 to 66% faster
Top-level scalar encode: 35 to 43% faster

One of those is a reversal. The exact-size preflight for very large strings now starts at 8 MiB rather than 1 MiB, because below that the second pass cost more than the reservation it saved: 75% slower on x86_64 and 160% slower on aarch64 for UTF-8 text at 1 MiB. The optimization was real and the threshold was wrong.

github.com/iliaal/fastjson

phpser 0.5.0: a signature is not a provenance proof

The signed decode path in phpser assumed that a validly signed frame came from phpser's own encoder, and used that assumption to skip work. It skipped the object pin, and it used add_new style inserts for assoc, object-property, and rowset schema keys on the grounds that the encoder would never emit a duplicate.

A valid HMAC proves key possession, not honest-encoder provenance. Anyone holding the key can hand the decoder a frame the encoder would never produce. A forged-but-validly-signed frame carrying a duplicate key could free an id-registered object on overwrite while a later back-reference still pointed at it, which is a use-after-free reachable by anyone who can sign. Objects are now pinned unconditionally for the decode pass, and the trusted paths use uniqueness-gated inserts.

Two more use-after-frees came out of the encoder, both through user hooks. A __serialize or __sleep hook that grows the array being walked through a by-reference alias reallocated the table under the element iterator; the walk now holds a reference so the write copy-on-write separates instead. Native serialize() still exhibits this on the same input. A nested hook that replaced a referenced __sleep() member name after phpser had borrowed the string pointer is the third, and the encoder now owns the selected property names until it finishes the object. Decoder work on crafted Zend hash collisions is bounded, so wire-controlled keys cannot turn an associative array into quadratic CPU.

The columnar format got better at the same time. TAG_TABLE deduplicates low-cardinality strings and equal packed-string vectors by content, which makes distinct-allocation rowsets 53% smaller and 44% faster to decode than igbinary on ARM. Table decode streams each column into the row arrays instead of materializing the columnar matrix first: on a 60,000 by 4 table, peak memory drops from 34.0 MB to 30.0 MB with no speed change, and a rejected frame never pays for the rows it claims.

github.com/iliaal/phpser

php_clickhouse 0.11.0: values that came back different

These are the kind of bug you don't notice until a number is wrong in a report.

Float32 reads round-tripped through %.6g, which drops significant digits. toFloat32(123456789) read back as 123457000. Reads now return the exact value the server sent, with the full binary expansion, so toFloat32(0.55) is 0.550000011920929. Inserting a float outside the column's range throws instead of storing ±INF.

A compression setting of 2 was silently downgraded to LZ4 rather than selecting ZSTD. The option now accepts 0/1/2, the strings "none"/"lz4"/"zstd", and bool, and throws on anything else. Bool inserts accept only true/false, 0/1, and those four values as strings; the string "false" previously stored true.

Map decoding produced PHP arrays with duplicate keys, because the duplicate check went through zend_hash_str_add_new(), which skips the existence test and appends a second bucket under the same key instead of reporting the collision. Associative decoding now rejects a Map whose entries would collapse onto the same PHP array key, and a new mode gives you the lossless form:

$rows = $ch->select('SELECT m FROM t', [], ClickHouse::MAP_AS_PAIRS);  // ordered [key, value] pairs

ClickHouseStatement joins cycle collection, so a statement holding an object cell stops leaking its rows until request shutdown. A failed TLS handshake stops leaking the peer certificate and its chain, about 4.4 KB per rejected connection. And selectStream() works on a result carrying an untyped NULL column when memory_limit is set, which php-fpm sets by default. On 32-bit PHP, protocol integers and DateTime values wider than zend_long come back as decimal strings instead of wrapping negative.

github.com/iliaal/php_clickhouse

mdparser 0.5.0: less memory, same output

The output buffer used to reserve an exact size for every document. It now seeds a roughly 1.25x reserve capped at 1 MiB, so ordinary documents reallocate less, sparse input stops reserving output it never produces, and dense input past the cap grows by doubling. Heading-anchor side buffers are released as each heading is flushed instead of held for the document. Adjacent AST text fragments are coalesced into one text node, which cuts the callback-driven array overhead that showed up on AST-heavy workloads.

toInlineHtml() got the worst of the old behaviour. It appended multiline content one byte at a time, dropped line-leading inline delimiters, and let its per-line sentinel surface inside code and LaTeX spans that crossed a line break. It now bulk-appends content runs and preserves both the delimiters and literal U+200B.

Two GitHub Flavored Markdown gaps closed. Options::github() enables alerts as well as footnotes, and a bare URL containing a percent sign autolinks: http://a.com/x%20y used to stop the scan at the percent and stay literal text. Fenced code whose info string entity-decodes to a language- prefix no longer gets a second one prepended, so language-php produces class="language-php".

The vendored md4c moved to master 10c0158, which lets the local code-span line-break patch go away now that upstream carries it and picks up a bounds guard on the table-alignment dash scan. Zend memory-limit bailouts now release md4c's libc allocations before the request aborts.

github.com/iliaal/mdparser

phonetic 0.4.0: constants that cannot be confused

bmpm() takes a name type and an accuracy, in that order:

function bmpm(string $string, int $name_type = BMPM_GENERIC, int $accuracy = BMPM_APPROX, string $language = ""): string

BMPM_APPROX was 1 and BMPM_EXACT was 2. BMPM_ASHKENAZI is 1 and BMPM_SEPHARDIC is 2. So bmpm($name, BMPM_APPROX), which is a natural thing to write and wrong, ran as an Ashkenazi encode and returned a plausible answer. Nothing rejected it because nothing could tell the difference.

The accuracy constants are now 10 and 20, disjoint from the name-type range, so the same call is rejected by argument validation. This is breaking only for code that hard-codes the numeric values 1 and 2 for the accuracy argument; code using the constant names is unaffected. Forcing $language = "any" also raises a ValueError now, since that is the default ruleset label rather than a language; pass an empty string for auto-detect.

The rest is BMPM performance and bounds. The final-rule merge sorts once instead of running an O(R²) insert-sort, BMPM_MAX_PREFIX_DEPTH drops from 16 to 6 to bound the prefix dual-encode fan-out, and phoneme-set growth uses overflow-safe allocation. One earlier optimization got reverted: routing 1 to 3 element compares through memcmp() cost 5 to 6% of encode time, so the rule-matching inner loops compare code points inline again. double_metaphone() stops encoding once both codes reach max_length, and the match helpers skip the second encode when the first operand is unencodable or the two operands are identical.

github.com/iliaal/phonetic

What a stabilization release actually costs

Across these nine changelogs there is almost no new capability. One border method, one set of interfaces, a few error-code constants, one lossless Map mode. The rest of it is a Float32 that finally comes back the way the server sent it, a signed frame trusted for exactly what a signature proves and nothing further, and a bmpm() accuracy constant that can no longer be mistaken for a name type.

The part I didn't expect when I started this cycle is how much of the performance work turned out to be the same job. Streaming the workbook save back, re-latching the sandbox per chunk instead of per row, reading the clock once per batch, moving the string preflight threshold from 1 MiB to 8 MiB, comparing three code points inline instead of through memcmp(). None of that is a new algorithm. It is the cost of correctness, found and paid down after the correctness landed. Some of it stays paid: compat construction in fast_uuid is a third slower on purpose, and a fastchart stock series with a near-DBL_MAX outlier costs 4x what it did. Those are the trades I would make again, and they belong in the changelog rather than in the rounding.

How to Choose the Right Web Development Technology for Long-Term Business Growth

Mon, 27 Jul 2026 06:58:24 +0000

Building a website today is no longer just about creating an online presence. Modern businesses expect their websites to generate leads, support customers, integrate with business tools, and grow alongside the company. This is why selecting the right web development technology is one of the most important decisions during the planning stage.

Many organizations rush into development by choosing the latest programming language or framework without considering whether it actually suits their business goals. A better approach is to evaluate your project requirements, compare available technologies, and work with experienced developers who can recommend the best solution.

Start with Your Business Goals

Every web development project is different. An online store has different requirements than a SaaS platform, while a corporate website has different priorities than a customer portal.

Before choosing a technology, ask yourself a few questions.

How many users do you expect during the first year? Will the website need third-party integrations? Are you planning to launch a mobile application later? How frequently will new features be added?

The answers help determine whether your project needs rapid development, enterprise-level scalability, advanced automation, or a combination of all three.

When business goals are clearly defined, selecting the right technology becomes much easier.

Why Programming Language Selection Matters

The programming language behind your website influences its speed, flexibility, maintenance costs, and future scalability. Although there are many excellent backend technologies available today, PHP and Python remain among the most widely adopted choices.

PHP has been a cornerstone of web development for years, powering millions of websites and popular content management systems. It offers excellent compatibility with hosting environments and is especially well suited for content-driven websites and eCommerce platforms.

Python has gained tremendous popularity because of its clean syntax, rapid development capabilities, and extensive ecosystem. It is widely used for AI applications, automation, machine learning, and complex web platforms.

If you're evaluating which language better suits your project, this comprehensive comparison of PHP vs. Python explains the advantages, disadvantages, performance considerations, and ideal use cases for each technology. Reviewing both options before starting development can prevent expensive changes later.

Performance Depends on More Than the Language

Many business owners assume that choosing a programming language automatically determines website performance. In reality, performance depends on several factors working together.

Application architecture, database optimization, caching strategies, image optimization, hosting infrastructure, and code quality all contribute significantly to loading speed.

Even the fastest programming language cannot compensate for poorly written code or an inefficient database design. Likewise, a well-optimized application built with mature technologies often outperforms newer frameworks that have not been implemented correctly.

Businesses should focus on hiring developers who understand performance optimization rather than chasing technology trends.

Scalability Should Be Planned from Day One

One common mistake businesses make is building only for current requirements.

A website that serves a few hundred visitors today may need to support thousands of daily users within a couple of years. Customer expectations also continue to evolve, requiring businesses to introduce new features such as payment gateways, CRM integrations, customer dashboards, APIs, marketing automation, and analytics tools.

Planning for future growth from the beginning helps avoid complete redevelopment later.
Scalable architecture allows developers to add new features without affecting existing functionality, saving both time and development costs over the long term.

Finding the Right Development Team

Choosing the right technology is only part of the equation. The experience of your development partner often has an even greater impact on the final outcome.

Professional development companies understand project planning, security, quality assurance, deployment, maintenance, and ongoing support. They also follow coding standards that make applications easier to maintain as businesses grow.

If you're researching experienced agencies, this curated list of top web development companies in India provides a useful starting point for comparing companies based on their expertise, services, client experience, and technical capabilities.

Rather than selecting a company based solely on pricing, businesses should evaluate communication quality, project management processes, technical knowledge, and post-launch support.

Security Must Be Built into Every Project

Website security is no longer optional.

Cyber threats continue to become more sophisticated, affecting businesses of every size. Data breaches not only result in financial losses but can also damage customer trust.

Secure web development includes validating user input, protecting sensitive information, implementing proper authentication systems, encrypting data, and performing regular security testing throughout development.

Developers should also follow established industry standards instead of relying solely on custom security practices. The OWASP Top 10 is widely recognized as one of the most trusted resources for understanding common web application vulnerabilities and implementing effective security measures.

Making security part of the development process from the beginning is significantly more effective than attempting to fix vulnerabilities after launch.

Maintenance Is Just as Important as Development

Launching a website is only the beginning of its lifecycle.

Software updates, server maintenance, security patches, feature enhancements, bug fixes, and performance improvements are all ongoing responsibilities.

Organizations that neglect maintenance often experience slower websites, compatibility issues, and increased security risks over time.

Regular monitoring and continuous improvements ensure the application remains stable while adapting to changing business requirements and customer expectations.

Businesses should include long-term maintenance planning in their initial project budget instead of treating it as an afterthought.

The Future of Web Development

Web development continues to evolve rapidly. Artificial intelligence, cloud-native applications, headless architectures, progressive web apps, and API-driven ecosystems are becoming increasingly common across industries.

However, successful businesses rarely adopt every new technology simply because it is popular.

Instead, they evaluate whether a technology aligns with their long-term objectives, technical resources, and customer needs.

A well-planned project built on reliable technologies often delivers better results than one that constantly changes direction to follow emerging trends.

By combining thoughtful planning with experienced development professionals, businesses can build websites that remain competitive for many years.

Conclusion

Selecting the right web development technology requires more than comparing programming languages. It involves understanding your business goals, planning for future growth, prioritizing security, and working with developers who can build scalable, maintainable solutions.

Whether you choose PHP or Python, the most successful projects are those built on careful planning rather than assumptions. Taking the time to evaluate your options, learn from trusted resources, and partner with experienced professionals will help ensure your investment continues delivering value as your business grows.

PHP vs. Python: Which Programming Language Is Better for Modern Web Development?

Mon, 27 Jul 2026 06:38:27 +0000

Choosing the right programming language is one of the most important decisions when starting a web development project. The technology you select affects everything from development speed and scalability to maintenance costs and future upgrades. Among the many options available today, PHP and Python continue to dominate the web development landscape because of their maturity, large communities, and extensive frameworks.

Although both languages are capable of building powerful applications, they serve different purposes depending on project requirements. Understanding their strengths and limitations can help businesses make a smarter investment and avoid unnecessary technical challenges later.

Why the Choice of Programming Language Matters

A web application is expected to do much more than simply display information. Modern businesses require secure platforms, fast loading times, seamless integrations, and the ability to scale as traffic grows. The programming language used behind the scenes plays a major role in achieving these goals.

Rather than selecting a language based solely on popularity, businesses should evaluate their project requirements, expected user base, available budget, and long-term business objectives. A well-informed decision often results in lower maintenance costs and a better user experience.

PHP: A Reliable Choice for Web Applications

PHP has powered websites for more than two decades and continues to be one of the most widely used server-side programming languages. Popular content management systems such as WordPress, Drupal, and Joomla are built using PHP, making it an excellent option for content-driven websites and eCommerce stores.

Modern PHP frameworks like Laravel and Symfony have significantly improved developer productivity. They include built-in features for authentication, routing, database management, and security, allowing developers to build sophisticated applications much faster than before.
PHP is especially suitable for businesses that want to launch dynamic websites quickly while keeping hosting and development costs relatively affordable.

Python: Built for Innovation and Scalability

Python has become one of the fastest-growing programming languages because of its simplicity and versatility. Its clean syntax allows developers to write readable code while reducing development time. Beyond traditional web development, Python has become the preferred language for artificial intelligence, machine learning, automation, and data science.

Frameworks such as Django and Flask provide everything needed to develop secure and scalable web applications. Django, in particular, includes numerous built-in security features that help developers create robust applications without relying heavily on third-party packages.

For startups and enterprises planning to integrate AI or advanced analytics into their products, Python offers exceptional flexibility.

Comparing PHP and Python

Choosing between these two technologies depends largely on the type of application you plan to build.

PHP performs exceptionally well for websites, blogs, customer portals, business applications, and online stores. It has a mature ecosystem, affordable hosting options, and a massive developer community.

Python is often preferred for SaaS platforms, automation tools, AI-powered products, and applications involving large amounts of data processing. Its versatility allows developers to expand projects into areas beyond traditional web development.

If you're looking for a detailed comparison of PHP vs. Python, this guide explains their differences in performance, learning curve, frameworks, scalability, and ideal use cases, making it easier to determine which language aligns with your business goals.

Performance Depends on More Than the Language

Many people ask which programming language is faster. In reality, application performance depends on several technical factors working together.

Database optimization, caching strategies, server configuration, application architecture, and code quality often have a greater impact than the programming language itself.

Recent PHP versions have introduced substantial performance improvements, while Python frameworks continue evolving to support asynchronous processing and better scalability. When implemented properly, both technologies can deliver excellent performance for modern web applications.

Development Speed and Maintenance

A shorter development cycle often means lower project costs. Python's clean syntax enables developers to write fewer lines of code, making it particularly attractive for projects with complex business logic or data processing requirements.

PHP, however, has also become highly efficient through frameworks like Laravel, which simplify routine development tasks. Developers can quickly build secure applications using pre-built modules for authentication, validation, and database management.

From a maintenance perspective, both languages benefit from active communities that regularly release updates, security patches, and new packages.

Security Best Practices

No programming language is automatically secure or insecure. Security depends on how an application is designed and maintained.

Developers should always implement secure coding practices, including proper input validation, encrypted passwords, prepared SQL statements, access control, and regular software updates. Fortunately, both Laravel and Django provide numerous built-in security features that help reduce common vulnerabilities.

Businesses should also schedule regular security audits to ensure their applications remain protected as new threats emerge.

Choosing the Right Development Team

Selecting the right technology is only part of the equation. The expertise of the development team has an even greater influence on the success of a project.

Before hiring a development company, consider their technical experience, previous projects, communication process, and post-launch support. Reviewing case studies and client feedback can provide valuable insights into their capabilities.

If you're planning a Python project, exploring this list of top Python Development Companies in India is a great starting point. It highlights experienced companies known for building scalable web applications, enterprise software, AI solutions, and custom Python-based products.

A knowledgeable development partner will recommend the most suitable technology based on your business needs instead of simply following industry trends.

The Future of PHP and Python

Both PHP and Python continue evolving alongside modern web technologies.

PHP remains highly relevant for CMS platforms, business websites, customer portals, and eCommerce applications. Ongoing improvements in performance and framework capabilities ensure it remains competitive for years to come.

Python's popularity continues to grow because of its expanding role in artificial intelligence, cloud computing, automation, and data analytics. Organizations developing intelligent software products often choose Python because of its extensive ecosystem and long-term flexibility.

In many cases, businesses combine multiple technologies within a single application. APIs and microservices allow PHP and Python to work together efficiently, enabling organizations to take advantage of each language's strengths.

For developers and business owners who want to stay updated with current web standards, the MDN Web Docs provides comprehensive guidance on modern web development practices, security, and performance optimization.

Conclusion

The decision between PHP and Python should be based on your project's objectives rather than on which language is considered more popular.

PHP continues to be an outstanding choice for websites, CMS platforms, and eCommerce development because of its mature ecosystem and cost-effective deployment. Python stands out for applications involving automation, artificial intelligence, machine learning, and advanced data processing.

By understanding the strengths of each language and partnering with experienced developers, businesses can build scalable applications that support both current requirements and future growth.

Frequently Asked Questions

Is PHP still a good choice in 2026?

Yes. PHP remains one of the most widely used server-side programming languages and continues to power millions of websites and business applications worldwide.

Why do companies choose Python for web development?

Python offers clean syntax, rapid development, excellent scalability, and strong support for AI, machine learning, and automation, making it ideal for modern software products.

Which language is easier for beginners?

Python is generally considered easier because of its simple and readable syntax. However, PHP is also beginner-friendly, especially for developers interested in building websites.

Can PHP and Python be used together?

Absolutely. Many organizations use PHP for their web interface while leveraging Python for data processing, AI models, automation, or analytics through APIs.

How should businesses choose between PHP and Python?

Businesses should evaluate their project requirements, expected scalability, budget, technical goals, and long-term maintenance strategy before making a decision. Working with an experienced development partner can also help identify the most suitable technology stack.

Creating Custom Elementor Widgets: A Developer's Guide

Sun, 26 Jul 2026 16:39:42 +0000

Actual PHP structure for building custom Elementor widgets — registration, controls, rendering — for when Elementor's stock widgets aren't enough.

Covers the widget class structure, adding editable controls (text, color, repeaters), proper output escaping, and common mistakes (skipping escaping, not namespacing classes, building one giant widget instead of focused ones).

Also flags something that trips a lot of people up: Elementor's widget registration hook name has changed across versions — always check current docs before building on a live client site.

Full writeup: https://amanurrahman.com/blog-post/custom-elementor-widgets-guide

Arabic search in WordPress: the matches it silently misses

Fri, 24 Jul 2026 23:41:33 +0000

Two hundred and fifty thousand articles, and the thing editors complained about was the search box. Not the accuracy of it. The wait. Type a name into the newsroom's admin search, go and do something else, come back.

That is the easy complaint, because it arrives. Someone tells you. What never arrives is the other one, and it took me far too long to notice it was missing: nobody has ever told me the search came back empty for a story we definitely published. Nobody ever will. A search that returns nothing does not look like a bug. It looks like proof you never covered it.

So we fixed the loud one, and left the quiet one running for years.

It is the same seam as an earlier piece on Arabic slugs: Arabic quietly breaking an assumption WordPress never knew it was making. Last time it was the URL. This time it is the search box.

What WordPress actually does with an Arabic query

Type a term into WordPress search and WP_Query builds this, near enough:

WHERE post_title   LIKE '%term%'
   OR post_excerpt LIKE '%term%'
   OR post_content LIKE '%term%'

That is the whole mechanism. Not a search engine, not an index, a substring test run three times per row. It knows nothing about words, and nothing at all about Arabic.

We measured what that means on a throwaway WordPress 7.0.2 and MySQL 8.0.35: one post per spelling, then the obvious searches.

you search	you get back
محمد	only the plain post
مُحَمَّد (with tashkeel)	only the tashkeel post
محمـــد (with tatweel)	only the tatweel post
أحمد (hamza alef)	only the hamza post
احمد (bare alef)	only the bare alef post
مصطفى (alef maqsura)	only the maqsura post
مصطفي (yaa)	only the yaa post
مكتبه (haa for taa marbuta)	nothing at all

Read that right-hand column again. Every search returns only its own exact spelling, and the last returns nothing at all, even though every term on the left is the same word to a human being. A reader who types a name without diacritics never sees the article that has them. Someone who writes أحمد never finds احمد. Someone who ends a word with ه instead of ة gets an empty page.

The one result that looks like a success is the exception that proves the point. Searching كتاب does return الكتاب. That is not the search understanding the definite article, it is the letters ك ت ا ب happening to sit inside الكتاب as a literal substring. Search وكتاب, the same word with a prefixed و, and you get nothing, because the bare word is no longer embedded in it.

The admin post list behaves identically to the front end, which is the part that matters, because that is where your editors live.

The same word, written three ways, and a reader means one thing by all of them. WordPress compares raw bytes with LIKE, so the three stay three different strings and none finds the others. Fold them with the same normaliser and they collapse to a single token that matches every time.

The database already knows. WordPress never asks it.

This is the part that genuinely surprised me.

WordPress does not inherit your server's collation. It forces its own onto its tables, utf8mb4_unicode_520_ci, whatever MySQL's default happens to be. And that collation is not naive about Arabic. Ask MySQL directly, with an equality test:

SELECT 'مُحَمَّد' = 'محمد' COLLATE utf8mb4_unicode_520_ci;   -- 1

One. True. The collation folds the diacritics away and says these are the same string. On MySQL 8's utf8mb4_0900_ai_ci it folds tatweel as well.

Now ask it the way WordPress asks it:

SELECT 'مُحَمَّد' LIKE '%محمد%' COLLATE utf8mb4_unicode_520_ci;   -- 0

Zero. Same data, same collation, same server, opposite answer. Wildcard pattern matching does not apply the collation's character folding, so every piece of Arabic knowledge sitting in your database is thrown away the moment you wrap the term in %. We tested four collations. Under =, the good ones fold. Under LIKE '%…%', all four return zero.

The capability was already in the building. The search architecture walks straight past it.

The identical pair, the diacritic-marked spelling and the plain one, under WordPress's own collation. Compared with =, the collation folds the tashkeel away and returns 1: they are equal. Compared with LIKE and a wildcard, that folding is skipped and it returns 0. Same data, same collation, opposite answer, and WordPress search asks with LIKE.

Even reaching it would not be enough

It is tempting to stop here and go looking for a way to make WordPress compare with =. It would not save you, and the measurements show why.

A collation folds accents. Tashkeel are accents, combining marks that sit on top of a letter, which is exactly why they fold.

Hamza is not an accent. أ and ا are different letters. So are ى and ي. So are ة and ه. None of them fold, in any collation we tested, under any comparison. And these are not edge cases in Arabic, they are the ordinary daily variation: the same name spelled أحمد by one editor and احمد by another, the same word ending ى in one headline and ي in the next.

So the database will hand you diacritics for free if you ask it correctly, and it will never hand you the rest. Anything that actually works has to normalise the text itself, deliberately, on both sides of the comparison.

What it costs, and why the broken searches are the expensive ones

The other half of this is the half your editors do complain about.

A LIKE with a leading wildcard cannot use an index. Not "is slow to use one", cannot use one, ever. EXPLAIN on the query WordPress generates says it plainly:

type: ALL     key: NULL     rows: 50013

Full scan, no key, every row. We seeded 50,000 realistic Arabic posts and timed it with a fresh PHP process per run, because repeating it inside one process makes WordPress's in-request cache report a fraction of a millisecond, which is a lie:

a term matching one post: about 215 ms
a term matching nothing: about 225 ms

The search that finds nothing is the slowest, and that is not a rounding artefact. LIKE '%term%' gives up on a row the instant it finds the substring, so a row that matches is cheap: often the title matches and the long body is never read at all. A row that does not match has to be read to the last byte of every field before MySQL can be certain the word is absent. Proving absence is the expensive case. And in Arabic, the searches that come back empty are precisely the variant spellings in the table above.

You might expect LIMIT 10 to rescue this. It cannot, and MySQL says so in plain words. WordPress needs a total for pagination, so it asks for SQL_CALC_FOUND_ROWS, and the query plan reports the consequence itself:

Limit: 10 row(s) (no early end due to SQL_CALC_FOUND_ROWS)

Ten results on the page, every matching row enumerated to produce them.

The scan cost tracks table size, so a 250,000-article archive lands somewhere around a second per search, per concurrent searcher, with no index able to help. (That figure is an extrapolation from the 50k measurement, not a measurement of a 250k table.)

Now put the two halves together. The searches that silently return nothing are the same searches that scan your entire archive in order to return nothing. In Arabic, those are every variant spelling your readers and editors actually type. The complaint you get and the complaint you never get are the same query.

What we built, and what it fixed

We did the obvious right thing, and it worked.

We built a table outside WordPress, on AWS, one row per article: id, title, body, author, categories. Every time a post was published, updated or deleted, that row was kept in step. Search stopped asking the WordPress database to scan a quarter of a million rows and started asking a store built for the job. Public search had already been handed off to a Google Custom Search Engine, so between the two, search stopped being the thing anyone raised in a meeting.

(That table later grew into something much larger, a recommendation engine that learns what a reader is interested in and chooses their next article. That is a story for another day.)

By every measure we were watching, we had fixed search.

What it did not fix

We never normalised the Arabic.

The new table was faster. It was still storing and matching the same raw strings, with the same orthographic variation, in the same literal way. A reader typing محمد still missed مُحَمَّد. أحمد still missed احمد. مكتبه still found nothing. We had rebuilt the entire search path, moved it to another cloud, and put a proper store underneath it, and every one of those searches failed exactly as it had before.

That is the lesson, and it took us years to see it: the speed problem was an infrastructure problem, and the matching problem never was. Scale, indexes and a store designed for querying will fix a scan. None of them will turn two spellings of the same word into the same token. Normalisation is a text problem, and if you do not solve it, it follows you to AWS.

And because nobody ever complains about a search that returns nothing, nothing ever forced the issue. The loud problem got an entire re-architecture. The quiet one just carried on.

The layer we were missing

The fix is small, and it is the same fix wherever your index lives.

Normalise both sides. Keep a normalised copy of the searchable text, index that, and put every incoming query through the identical normaliser before matching. Both halves matter: normalise only the stored text and a query carrying diacritics still misses, normalise only the query and it misses the stored variants.

What the normaliser has to do:

Strip the diacritics. Tashkeel are combining marks (U+064B to U+0652 and friends). Remove them entirely.
Strip tatweel (U+0640). It is decoration and carries no meaning.
Unify the alef forms. أ إ آ ٱ all become ا.
Unify ى to ي, and decide about ة to ه. These are conventions, not truths. Pick one, apply it to both sides, write it down.
Strip the definite article الـ, so الكتاب and كتاب fold to one token. Guard it, so it only comes off when enough of the word is left to still be a word, otherwise ال on the front of a short word gets eaten too. And stop there. It is tempting to strip the single-letter prefixes و ف ب ك ل as well, but those letters begin ordinary words, so بيت would lose its ب and فكرة would become كرة, a genuinely different word. So وكتاب will not fold to كتاب, and that conservative choice is the correct one.
Leave Latin alone. Newsroom copy is full of WordPress, AWS, S3 and half-transliterated terms. A normaliser that mangles those breaks more than it fixes.

Do that and the table from earlier collapses into a single row: every spelling of محمد, however it was typed, becomes one token that matches all the others. And because the normalised copy is matched through an index instead of a leading-wildcard scan, the query that used to take a second stops scanning the table at all.

And none of this needs a cloud. The story above happened to run through a table we put on AWS, but that was our answer to scale, not to matching. On an ordinary single-server WordPress, the same normalised copy in the same database, with the query folded the same way, fixes both the misses and the scan with nothing external at all. That is the layer we were missing, and it would have been missing just as badly on one server as on twenty.

One change, both complaints.

The plugin

The whole fix is one file. It goes in wp-content/mu-plugins/, and in its default mode it needs nothing else: no cloud, no service, no configuration.

composer require mantekio/wp-arabic-search

One catch: Composer installs it in a subfolder, mu-plugins/wp-arabic-search/, and WordPress only loads files sitting directly in mu-plugins/. So on a standard WordPress site Composer reports success and the plugin never runs. Stacks like Bedrock ship an autoloader that handles this; otherwise add the one-line loader from the README, or copy the plugin file into mu-plugins/ by hand instead. Not both: loading it twice is a fatal error.

On save it folds everything searchable about a post, title, excerpt and body, into one normalised column in a shadow table with a real FULLTEXT index, and rewrites WordPress search to match against that column through the identical normaliser. The public site and the wp-admin post list both run through WP_Query, so both are fixed at once. Build the index over what you already have with one command:

wp arabic-search reindex

Media gets the same treatment, which turned out to matter more than expected. An attachment keeps its text in four places: the title, the caption, the alt text and the filename. All four go into the same column, so a picture captioned in Arabic is findable by that caption, and صورة-بيروت.jpg is findable by its own name. WordPress does not search alt text at all, so on that one the plugin is not restoring parity, it is adding something core never had. This changes what the Media Library can find, not what appears anywhere else: the plugin decides which rows match the text, and WordPress still decides which post types and statuses are allowed in the results.

It ships with two modes, because the normaliser is the reusable part and the index is not. The default, index, is the self-contained one just described. The other, normaliser, maintains nothing and rewrites nothing: it exposes the normalising function and fires an action carrying the normalised text on every save, so a pipeline that indexes somewhere else (the AWS table we built, OpenSearch, anything) can fold its stored text and its queries with the same code. That is the guarantee that actually matters, and it is the one we did not have for years: both sides normalised by identical code.

define( 'WPAS_MODE', 'normaliser' );

One thing it deliberately refuses to do. InnoDB does not index words shorter than three characters, which in Arabic covers من, في, ما and عن: real words, typed constantly. An index that has never seen a word cannot find it, so requiring one would return an empty page for a search plain WordPress answers perfectly well. That is exactly the failure this article is about, and it would have been ours. So the plugin drops those tokens rather than requiring them, and where a search contains nothing else it hands the query back to core's LIKE untouched. Search a two-letter word and you get precisely what WordPress would have given you; search two words where only one clears the threshold and the long one still matches. The rule it follows is that where it cannot help, it stands aside rather than answer worse than the search it replaced. There is nothing to configure for this, and no reason to go changing innodb_ft_min_token_size on your server: it needs a MySQL restart and a rebuild of every full-text index on the box, and it buys you nothing here.

Which raises the question any search tool eventually gets asked, usually by an editor who is certain the article exists: why did this not match? Answering it used to mean reading the source, so there is now a command that just tells you.

$ wp arabic-search explain "من المكتبة"
normalised:  من مكتبه

+--------+------+--------------------------------------------------+
| token  | used | reason                                           |
+--------+------+--------------------------------------------------+
| من     | no   | shorter than innodb_ft_min_token_size (3)        |
| مكتبه  | yes  | indexable                                        |
+--------+------+--------------------------------------------------+

matches with: MATCH(search_text) AGAINST ('+مكتبه' IN BOOLEAN MODE)

The folded form, every token with whether it was used and why not, and the exact query that runs. It is the smallest feature in the plugin and the one I would miss most, because "search is broken" and "search is working exactly as designed on a word the index cannot hold" look identical from the outside, and this is the difference between them.

We eventually ran it against the real thing: a quarter of a million Arabic articles, plus half a million media items, on a copy of a live newsroom archive. One search settles the whole argument.

searching مُحَمَّد across 250,000 articles	results	time
WordPress	1	4.8 s
with the plugin	28,238	0.55 s

One. Out of twenty-eight thousand articles that contain that name, plain WordPress found a single one, because only one of them happened to spell it with exactly those diacritics. The other 28,237 were in the database the whole time, and no one searching for that name would ever have seen them.

The speed is the part you would have put in the ticket. The other column is the part nobody was ever going to report.

The rest of the numbers come from a controlled 50,000-post rig, where the match count can be dialled precisely, before and after:

matches, out of 50,000	default WordPress	with the plugin
1	about 215 ms	5 ms
500 (1%)	about 212 ms	10 ms
5,000 (10%)	about 230 ms	24 ms
25,000 (50%)	about 250 ms	115 ms
50,000 (100%)	about 310 ms	about 210 ms

EXPLAIN tells the same story as the clock. Before, every search was the full scan:

type: ALL        key: NULL        rows: 50013

After, the index drives it:

type: fulltext   key: search_ft   rows: 1

We had that bottom row wrong for a while, and the way it was wrong is worth repeating, because it is a trap set for anyone who benchmarks a text search. Our first measurement said the index lost on a term matching everything. It did not. The word we had seeded happened to sit near the start of every document, and since LIKE abandons a row the moment it finds a match, we were timing the scan at its luckiest: first few bytes, done, next row. Move the same word to the end of the same documents, and the result inverts.

a term matching all 50,000 rows	default WordPress	with the plugin
the word sits at the start of every document	140 ms	208 ms
the word sits at the end of every document	300 ms	205 ms

Read the plugin column first: it barely moves, because an index does not care where in the text the word happens to sit. Now read the other one, which doubles. We had benchmarked the scan's single luckiest case and called it a fair fight.

So the honest shape is a crossover, not a caveat. Against a term the scan actually has to read, the index wins across the entire range in the table above. Against a term positioned for the scan's best possible case, the index still wins until roughly 70% of the archive matches. A query that matches seventy per cent of a newsroom archive is not a search, it is a SELECT * with extra steps.

And the case that used to hurt most is now the cheapest. The old worst case was the search that came back empty, because proving absence meant reading every byte of every row. An index that finds nothing has nothing to read.

One honest word on where it is in its life. It is new, and it ships as 0.9.3. That it is already on its fourth release says something worth saying plainly: six rounds of adversarial testing found a bug every single time, and not one of them was found by reading the code.

The worst was in the first release. Search a two-letter Arabic word, من or في, and it returned nothing at all. The check meant to drop words too short for the index counted bytes, and an Arabic letter is two bytes, so every one of those words sailed through and became a required term the index had never held. A plugin whose entire argument is that Arabic search silently returns nothing had shipped a way to make Arabic search silently return nothing. Others followed: a health check that could not detect the condition it existed to detect, and a reindex command that announced success having written not one row.

They are all fixed, and every fix is in the changelog, but the pattern is the point. Each one was invisible from the code and obvious the moment something actually ran it. If this piece has a moral it is that one, and it applies to your search too: the failure that returns nothing looks exactly like the absence of anything to find.

What it has not yet had is months in a live newsroom, so it is out in the open under the GPL, on GitHub and Packagist, being hardened in daylight. The repository is github.com/mantekio/wp-arabic-search. Same loop as the pieces before it: the article explains the thinking, the repository is the plugin, the package is the one-line install, and each points at the other two.

Known limits

Being clear about what a tool does not do is part of the tool.

Single-letter prefixes are deliberately not stripped. Folding the definite article is safe behind a length guard; folding و ف ب ك ل is not, because they also start ordinary words, so it would turn بيت into يت and فكرة into كرة. The cost of that safety is that وكتاب does not fold to كتاب. Real prefix handling needs morphology, not a character map.
Folding is not stemming. It will not connect كتاب to its broken plural كتب, because Arabic plurals rewrite the word rather than append to it. That needs a root dictionary, and that is a different project.
The results are only as complete as the index. Nothing walks your archive when you install it, so run wp arabic-search reindex once. After that each save keeps its own row current, and wp arabic-search status exits non-zero the moment the index falls behind, goes stale, or carries rows for posts that no longer exist. Drift is something you get told about rather than something a reader discovers for you.
It costs disk, inside the database. A second normalised copy of your searchable text is still a copy. On that quarter-million-article archive the table came to about 1.1 GB, roughly 3 KB per article, though the FULLTEXT index on top of it was only 17 MB. Media is nearly free: attachments were two thirds of the rows and a sixteenth of the bytes.
Words the index cannot hold are correct, not fast. A search that falls back gets core's behaviour entirely, including core's speed, because it is core's query. On that same archive a two-letter word took about three seconds, exactly as it always had, while an indexed search of the same corpus took well under one. Nothing is worse than before. Nothing is better either.
Normalisation is lossy on purpose. Folding ة into ه, or ى into ي, will occasionally merge two words that genuinely differ. In an archive search that trade is nearly always worth it, but it is a trade: decide it deliberately and document it, rather than discovering it later.
Past a certain size, use a real search engine. OpenSearch ships an arabic analyser that does normalisation, stemming and stopwords properly, and gives you relevance ranking a LIKE will never have. If the archive is large and search matters, that is the destination. You still need the normaliser, because the same text problem travels with you. Ours did.

A quarter of a million articles, and the only thing anyone ever told us about search was that it was slow. So we made it fast. We built the table, moved the queries to AWS, kept it in sync on every post, the complaints stopped, and for a long time we took that to mean we had finished.

The searches that returned nothing never produced a single complaint, because a search that returns nothing looks exactly like a subject you never covered. The archive was full of articles nobody could find, and the silence around them read as success.

That is the part worth keeping, whatever your stack: complaints tell you about the loud failures and nothing at all about the quiet ones. Someone has to go and look.

That is how we run WordPress on AWS for newsrooms: fix what people report, then go hunting for what they cannot. If your archive is in Arabic and you have never tested what your search does with a hamza, let's talk.

WordPress cron behind a load balancer: fixing 'Missed schedule'

Wed, 22 Jul 2026 17:43:41 +0000

A newsroom schedules its lead story for six in the morning. At 6:05 it is not on the homepage. Nobody did anything wrong: the post was written, scheduled, saved, and its publish time has come and gone. There is no error, no failed job, nothing in the log. The post just sits in the admin list with a small grey label beside it, Missed schedule, as though it had quietly decided not to happen.

This is the worst kind of bug, the completely silent kind. And on WordPress spread across more than one server, it is barely a bug at all. It is what the default setup does under load, and the fix nearly everyone reaches for makes it worse, in a way that is genuinely hard to see.

wp-cron is not cron

The name lies. wp-cron is not a system scheduler. On a default install, WordPress checks for due jobs on a normal page load: near the end of a request it fires a non-blocking loopback call to wp-cron.php, which runs whatever is due. No visitors, nothing runs. A quiet site can sit for hours with nothing firing; a busy one runs its cron on the back of a random reader's page view.

On one server that is merely untidy. Put it behind a load balancer and it starts to fail in ways you cannot see. The loopback goes to your own domain, which resolves to the load balancer, which hands it to some instance, not necessarily the one that fired it. If an instance cannot reach the public hostname, the loopback silently does nothing. You now have a scheduler whose reliability depends on reader traffic and internal networking, for jobs like publishing the morning's lead story.

The fix everyone gives you, and the one it hides

Search this and every answer is the same two lines: switch the loopback off, and drive cron yourself.

define( 'DISABLE_WP_CRON', true );

* * * * * wget -q -O - https://www.example.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

We ran exactly that. Then, because a crontab lives on one machine and our machines come and go, we moved the trigger to a Lambda that hit the site every minute, so nothing depended on a single box staying alive. It looked correct. The request went out every minute, on schedule, forever.

And posts kept coming up Missed schedule.

Both rows want the same thing: the due events run on time. The top row triggers cron with an HTTP request, so it inherits everything sitting in front of the origin, a cache that can answer the same fixed URL without ever running PHP, a load balancer that can hand it to a draining node, and a web request that dies on a stuck lock or a mid-run recycle. The bottom row runs cron in-process with WP-CLI, so none of that is in the path.

The mistake is buried in that one-liner, and it is the same mistake whether a crontab or a Lambda fires it: we were still triggering cron with an HTTP request. Everything wrong with that survives the move to Lambda, because it has nothing to do with who makes the request and everything to do with the request itself.

Follow the path it takes. It hits your public URL, so it meets your CDN first. Our trigger was one fixed URL, wp-cron.php?doing_wp_cron, the same string every minute, which is precisely what a cache exists to answer without troubling the origin. So a good share of those tidy every-minute hits were served from cache as an empty 200, and PHP never ran. The dashboards were green. Cron was not running.

Past the cache it meets the load balancer, which sends it to whichever instance it likes, including one that is draining. If it does reach a live node, wp-cron.php runs as an ordinary web request, under the web server's timeout, holding a lock other requests respect for sixty seconds. Let one heavy job overrun that lock, or let the instance recycle mid-run, and cron wedges or dies with the queue half done. The publish_future_post event for the 6am story is somewhere in that unfinished tail.

None of it surfaces as an error. The trigger fires, something returns 200, and the post sits at Missed schedule until an editor asks why.

Stop hitting a URL

Here is the turn that fixed it, and it is smaller than it sounds: the reliable way to run cron makes no HTTP request at all.

wp cron event run --due-now

WP-CLI boots WordPress in a normal PHP process on the machine and runs the due events straight against the database. No page, so no CDN to cache it. No loopback, so no load balancer to misroute it. It runs in the CLI, which has no web timeout, so a slow job finishes instead of being cut off. Every fragile link in the HTTP path is simply not in this one.

That is the whole distance between "keep hitting the server so cron stays alive" and "run cron". Hitting a page keeps it triggered. It does not keep it finishing, on time, and finishing is the only thing a scheduled post cares about.

Which leaves one question, the one that turns this from a one-liner into a fleet problem: if cron now runs in-process on a machine, which machine?

Which machine?

Cron now runs in-process, which means it runs on whichever machine the crontab sits on. In a fleet, that innocent question is the whole problem, because there are only two obvious answers and both are wrong.

Pin it to one machine and you are back where you started. That machine is cattle: a deploy replaces it, a scale-in retires it, a health check recycles it, and your one crontab leaves with it. Cron stops, silently, and the 6am story misses again. A single runner is a single point of failure wearing a tidier hat.

So put it on every machine, bake it into the image, and let every node run cron. Now the opposite breaks. wp cron event run on each node executes the due events locally, against the shared database, in the same minute. The event that publishes the lead story fires on all of them. Readers get the newsletter three times, the post publishes and re-publishes, the feed importer runs in triplicate. The transient lock core uses for the loopback does not save you here, because each CLI process is its own world and, unless your object cache is shared, they cannot even see each other's lock.

Run everywhere, execute once

The answer is to keep cron on every node, so there is no single box to lose, and put one shared lock in front of the run, so only one node does the work each minute.

Every instance runs the trigger, so there is no single box to lose, but each run first tries to take a shared lock (a MySQL advisory lock, or a Redis key), and only the winner executes the due events. The runner records each successful pass, so a total stall is loud instead of silent.

Every node's crontab calls the same command every minute. The first thing it does is ask for a lock. Exactly one node gets it; the rest are turned away in a millisecond and exit having done nothing. The winner runs the due events and releases the lock. Next minute the race is run again, and it does not matter who wins.

For the lock you already have the one shared thing you need: the database. Every instance talks to the same MySQL, so a MySQL advisory lock is a coordinator with nothing new to deploy:

SELECT GET_LOCK('wp_fleet_cron', 0);

Ask for it with a zero-second timeout, run cron only if you got it, release it when you are done. There is a second reason to prefer this over the transient lock WordPress uses: an advisory lock lives on the database connection, so if the runner is killed mid-job, the connection closes and the lock releases itself. The stuck-lock failure that wedges the transient one for sixty seconds cannot happen here. If you run Redis across the fleet, a SET key value NX PX key does the same job; the point is that the lock is shared, not which store holds it.

Make the silence loud

One thing is still missing, and it is the thing that started all this. Elected and locked, cron runs correctly, right up until the day it does not: a bad deploy, a lock a broken database will not grant, a crontab that quietly stopped being installed. A scheduler that fails silently is the whole reason we are here.

So the runner writes down every successful pass, the time and the node that did it. That one record turns the unanswerable question, "is cron running?", into a check anything can make:

wp fleet-cron status || send-me-an-alert

It exits non-zero the moment the last run is older than it should be, so an outage pages you before an editor finds it. The missed 6am story stops being a mystery someone stumbles on and becomes an alert you already handled. It is the same rule that runs through our WordPress mail plugin: a failure you cannot see is worse than one that shouts.

The plugin

It is one file. Drop it into wp-content/mu-plugins/, add one line to wp-config.php, and run one command from system cron on every node:

define( 'DISABLE_WP_CRON', true );

* * * * * cd /var/www/html && wp fleet-cron run --quiet

Then hand the health check to your monitoring, so a stall reaches you rather than an editor:

wp fleet-cron status || send-me-an-alert

Or install it with Composer:

composer require mantekio/wp-fleet-cron

One catch: Composer installs it in a subfolder, mu-plugins/wp-fleet-cron/, and WordPress only loads files sitting directly in mu-plugins/. So on a standard WordPress site Composer reports success and the plugin never runs. Stacks like Bedrock ship an autoloader that handles this; otherwise add the one-line loader from the README, or copy the plugin file into mu-plugins/ by hand instead. Not both: loading it twice is a fatal error.

One honest word on where it is in its life. It is new, and it ships as 0.9.0. It has been exercised end to end against a real database and WP-CLI: a single runner elected out of five firing at once, a lock that frees itself when the holder is killed mid-job, the watchdog going loud the moment a run goes stale. What it has not yet had is months in a live multi-node fleet, so it is out in the open under the GPL, on GitHub and Packagist, being hardened in daylight rather than behind a curtain. The repository is github.com/mantekio/wp-fleet-cron. Same loop as the pieces before it: the article explains the thinking, the repository is the working plugin, the package is the one-line install, and each points at the other two.

Known limits

Being clear about what a tool does not do is part of the tool.

The lock assumes a single primary database. That is the normal case, and it is the one thing every node in a fleet already shares. On a multi-primary topology, or behind a connection pooler that hands one session to different callers, swap in a Redis key (SET key value NX PX); the plugin leaves a seam for it.
It assumes you can run system cron on the nodes. If your host forbids that, keep the loopback, but the watchdog still tells you the instant cron stops.
A long job serialises cron behind it. The lock is held for the length of a run, so a job that overruns the minute makes the next tick skip rather than stack a second copy on top. That is deliberate, you never want two, but a genuinely heavy job wants its own queue, not a seat in the cron tick.
Some managed hosts already run cron correctly for a fleet. Check what yours does before adding anything.

Publishing a post on time is the most solved problem in WordPress, on one server. Across a fleet, on the morning a scheduled lead has to be live at six, it turns out to be a small distributed-systems problem in a CMS costume, and the fixes are the dull, correct ones: run cron where nothing can cache or misroute it, let exactly one node act, and make the silence loud the instant it falls. None of it is clever. All of it is the distance between a scheduler you hope is running and one you know is.

That is the shape of running WordPress on AWS for a newsroom: the real problems hide inside the boring infrastructure, and the work is making the boring parts unbreakable. If a scheduled post has ever quietly failed to appear, and you would rather it never did again, let's talk.

WordPress White Screen of Death & Critical Error: Complete Fix Guide

Sun, 19 Jul 2026 17:51:15 +0000

Debugging WordPress White Screen of Death / Critical Error — a developer's checklist

Every WordPress dev eventually gets the panicked "my site is just blank" message. Here's the exact diagnostic order I use, from PHP fatal error basics to production-safe fixes.

Root cause: always a PHP fatal error. WSOD = blank page (WP_DEBUG_DISPLAY off). "Critical error" message = WP 5.2+'s wrapper around the same fatal.

Diagnostic order:

Enable WP_DEBUG_LOG, read /wp-content/debug.log for exact file + line
Rename /wp-content/plugins/ via FTP to isolate plugin conflicts (no admin access needed)
Rename active theme folder to rule out theme errors
Check WP_MEMORY_LIMIT
Re-upload core files if update was interrupted
Check for a silent PHP version bump by the host

Full writeup with cost breakdown for client work: https://amanurrahman.com/blog-post/wordpress-white-screen-critical-error-fix

Your WordPress says the email sent. It didn't.

Sat, 18 Jul 2026 16:45:34 +0000

A user tells you they never got the password-reset email. You check: WordPress says it sent. wp_mail() returned true. There is nothing in the logs, because there is nothing to log. The mail left the building and vanished.

This is the worst kind of bug. It is silent, it is invisible, and it happens in the one flow where the user is already locked out and already frustrated. And on a default WordPress install, it is not a bug at all. It is the design.

Why WordPress email is broken by default

Out of the box, wp_mail() hands your message to PHPMailer, which hands it to PHP's mail(), which hands it to sendmail on the web server. That path has no sending reputation, no SPF alignment, and no DKIM signature. To a modern mail provider, a message from a random web server, unsigned and unaligned, is indistinguishable from spam, so Gmail and Outlook quietly bin it. Often without even a bounce.

And wp_mail() reports none of this. Its entire failure vocabulary is a single false, and on the default path it usually does not even return that: sendmail accepts the message, so wp_mail() returns true, and the mail dies somewhere downstream where WordPress will never hear about it.

So the real problem is two problems. The mail is unauthenticated, and the failure is silent. Any fix has to solve both, or it has not fixed anything.

WordPress builds the same message either way. On the default path it goes to PHP's mail() and out unsigned, where wp_mail() still returns true. The plugin swaps only the transport: a PHPMailer subclass hands the finished message to the SES API, signed, and it arrives aligned.

Why the usual fix is a half-fix

Search for this problem and every answer is the same: install an SMTP plugin, point it at a real mail service, done. WP Mail SMTP, Post SMTP, and a dozen others all do it, and they do fix the authentication half. Your mail now goes through a reputable server that signs it.

But look at where the credentials live. An SMTP plugin hooks phpmailer_init, sets $phpmailer->Host, $phpmailer->Username, and $phpmailer->Password, and it has to get those values from somewhere. That somewhere is the database, in wp_options.

Sit with what that means. Your SMTP username and password, the ones that let anything send mail as your domain, are now sitting in a table that ends up in every place a database ends up. The nightly backup. The S3 bucket that backup lands in. The staging clone a contractor pulled last month. The dump you emailed yourself to debug something. Anyone who touches any copy of that database can now send mail as you, DKIM-signed by your own domain, and there is no fingerprint that says it was not you.

For a brochure site, that is a small risk. For a newsroom whose domain reputation is an asset, it is the sort of thing that should keep you up at night. The half-fix traded a deliverability problem for a credential-management one, and then hid the trade in a settings screen.

The architecture: three moves

The fix is three decisions, and each one removes an entire class of the problem rather than mitigating it.

One: send through the SES API, not SMTP. SMTP means a username and a password, which means a secret at rest. The Amazon SES API is a signed HTTPS request. There is no long-lived password in the flow at all.

Two: authenticate with an IAM role, not a stored key. This is the move that makes the difference. If your WordPress runs on AWS compute, EC2 or ECS, the instance or task carries an IAM role, and AWS hands short-lived credentials to the machine automatically, rotated for you, never written down. The plugin reads them from the instance metadata endpoint at send time and uses them for that one request. Nothing is stored. Not in the database, not in wp-config.php, not on disk. There is no secret to leak because there is no secret at rest.

Three: replace only the transport, and reimplement nothing. This is the move that keeps the plugin honest, and it has a story behind it.

A seam, not a fork

WordPress 5.7 added a filter called pre_wp_mail. Return a non-null value from it and wp_mail() short-circuits, handing you the whole job. It is tempting to take it: hook the filter, build the SES call, return true.

It is also a trap, and I know the shape of this trap well, because I walked into a version of it once already. The last must-use plugin I wrote forked a core function, a copy of sanitize_title_with_dashes(), because core gave me no seam. That fork then drifted from core for three releases without anyone noticing, dropping an entire block of character handling, until it was mangling exactly the Arabic text it was meant to protect. The postscript on that article is a confession: a hand-copy of a core contract rots silently.

Short-circuiting pre_wp_mail would be the same mistake in a new costume. Take over wp_mail() and you now own its entire contract: header parsing, Cc and Bcc, Reply-To, content type, charset, attachments, and every wp_mail_* filter a hundred other plugins hook into. Reimplement all of that and your copy will drift from core the moment core changes, silently, exactly like last time.

So this plugin reimplements none of it. Core builds its own PHPMailer object, but only when the global is not already one:

global $phpmailer;
if ( ! ( $phpmailer instanceof PHPMailer\PHPMailer\PHPMailer ) ) {
    // ...core builds the mailer...
}

That if is the seam. Hand core a subclass of PHPMailer before it looks, and it uses yours. Core still assembles the entire message, still honours every filter, still does everything it always did. The subclass overrides one method, postSend(), the point where PHPMailer would normally talk to the transport, and ships the finished message to SES instead:

class WPSES_Mailer extends \PHPMailer\PHPMailer\PHPMailer {
    public function postSend() {
        $raw  = $this->getSentMIMEMessage();     // core built this, not us
        $sent = wpses_send_raw( $raw, /* recipients */ );

        if ( is_wp_error( $sent ) ) {
            // Throwing lands in core's own wp_mail_failed path.
            throw new \PHPMailer\PHPMailer\Exception( $sent->get_error_message() );
        }
        return true;
    }
}

We take the fully assembled MIME message that core produced and put it on the wire. We replace the transport and nothing else. There is no contract to reimplement, so there is nothing to drift. The lesson from the slug plugin, learned the expensive way, is baked into the architecture of this one: when core gives you a real seam, take the seam, never the fork.

Fail loudly, because the alternative is what we are here to fix

Go back to the password reset that vanished. The reason it vanished is that the failure was silent. So the cardinal rule of this plugin is that it is never silent.

When SES refuses a message, it tells you exactly why: an unverified sender, a sandbox restriction, a throttle. The plugin does not swallow that into a bare false. It logs the real SES error code, fires an action other code can hook, and, by throwing, lets the failure land in core's own wp_mail_failed so anything already listening for mail failures keeps working. A false is not a diagnosis. The SES error is.

And there is one thing the plugin pointedly refuses to do: fall back to PHP mail(). A fallback feels like the safe, considerate choice, and it is the exact opposite. Falling back means the mail appears to send, wp_mail() returns true, and the message lands in spam, which is the silent failure we started with, dressed up as resilience. A loud failure gets noticed and fixed. A silent success that lands in spam is never even seen.

The same principle governs what happens when the plugin is misconfigured. It does not shrug and let WordPress use sendmail. It refuses to send, and says why, on every admin screen and in the log. A must-use plugin that quietly stands aside is worse than no plugin at all, because now you believe your mail is going through SES when it is going straight to the spam folder.

Same rejected send, two outcomes. The plugin throws, so the failure lands in core's own wp_mail_failed with the real SES reason and wp_mail() returns false. The path it replaces swallows the error and returns true, and the message is gone with nothing logged.

The part every tutorial skips: bounces and complaints

Send real mail at any volume and some of it will bounce: addresses go dead, mailboxes fill up, people hit the spam button. Amazon SES watches those two numbers, your bounce rate and your complaint rate, and it is not being advisory. Cross the thresholds and it throttles your sending; stay across them and it suspends the account outright. One careless WordPress install, cheerfully emailing a list of addresses that stopped existing years ago, is enough to put a whole domain's ability to send at risk.

WordPress, left alone, will do exactly that. It has no memory of a bounce. Ask it to email a deleted address a thousand times and it will try a thousand times, because nothing in wp_mail() ever hears that the last nine hundred and ninety-nine failed.

So the plugin keeps the memory WordPress lacks. SES publishes every bounce and complaint to an SNS topic; the plugin exposes one endpoint for that topic, writes each dead or complaining address to a suppression table, and checks that table before every send. An address that hard-bounced or marked you as spam is simply never sent to again. That one feedback loop is most of the distance between a plugin that works on your blog and one you would run under a masthead. And if the plugin cannot record a bounce for a moment, a database blip mid-notification, it does not pretend it succeeded: it tells SNS so, and SNS holds the message and delivers it again, rather than letting a bounce quietly evaporate.

There is a sharp edge here that is easy to miss, and getting it wrong is worse than not having the feature at all. That SNS endpoint is a public URL. Anything on the internet can POST to it. An endpoint that believes whatever it receives is an open invitation: forge a notification and you could add any address you liked to the suppression list, silently blocking a site's own users from ever receiving its mail. So the endpoint trusts nothing by default. It pins the single SNS topic it is allowed to act on, and it verifies Amazon's cryptographic signature on every message before one row is written. A notification that is not from your topic, or whose signature does not check out, is refused. The last plugin taught the same lesson from the other side: the input you do not validate is the one that hurts you.

The traps worth naming

None of these are subtle once you know them, and every one has cost someone an afternoon. Named here so they cost you none:

Sandbox mode. A fresh SES account is sandboxed: it can only send to addresses you have verified, and the quota is tiny. Everything looks configured, and mail to real recipients is refused. The one-time fix is to request production access; the plugin's verify command tells you which mode you are in.
Region mismatch. SES identities are per-region. Verify your domain in eu-west-1, point the plugin at us-east-1, and every send fails for a reason that has nothing to do with your code. Send from the region you verified in.
An unverified From. SES will only send as an identity you own and have verified. The From domain has to be a verified identity, or the send is rejected outright, loudly, which is the whole point.
Alignment is DNS, not code. DKIM and SPF passing is what carries you to the inbox, and both are records you add, not switches the plugin can flip. Turn on Easy DKIM (the three CNAMEs SES hands you), set a custom MAIL FROM so SPF aligns, and DMARC then passes. The plugin signs the request; your DNS is what makes the result trusted.
The quotas are real. SES caps both a per-second rate and a rolling twenty-four-hour volume. A blast that ignores them does not queue politely, it fails. Know your limits before you lean on them.

Verifying it, and why the checker refuses to lie

A must-use plugin that sends mail silently is the problem. A plugin that tells you it is configured when it is not is the same problem wearing a badge. So the plugin ships a command whose entire job is to refuse to lie about its own health:

wp ses verify

It signs two real requests to SES with the exact code the send path uses, so a green result is proof the signing works, not a mock of it. It reports the things that actually break delivery: which region it is talking to, where the credentials came from (a role, ideally, not a stray key shadowing it), whether the From identity is verified, whether DKIM is on, whether the account is still sandboxed, the current quota, and whether the bounce topic is wired up. And it exits non-zero when any of that is wrong, so it composes:

wp ses verify || send-me-an-alert

Put that line in cron and a drifted config pages you before your users find it. This is the same discipline as the verify command in the slug plugin: a checker earns the right to say PASS by exercising the real thing, and it reports a failure it has not disproven rather than a reassuring green it has not earned. A check that cannot fail is not a check.

The plugin

It is one file. Drop it into wp-content/mu-plugins/, add a region and a From address to wp-config.php, give the machine an IAM role that can call SES, and WordPress mail goes through SES from the next send. No AWS SDK, no settings screen, no credentials in the database.

One honest word on where it is in its life: it is new. It is feature-complete and has been hardened through repeated adversarial review, with the SES signing checked against AWS's own test vectors, but I am shipping it as 0.9.0 while I run it end-to-end against a live SES account. So it is out in the open under the GPL, on GitHub and on Packagist, being finished in daylight rather than behind a curtain:

composer require mantekio/wp-ses-mail

One catch: Composer installs it in a subfolder, mu-plugins/wp-ses-mail/, and WordPress only loads files sitting directly in mu-plugins/. So on a standard WordPress site Composer reports success and the plugin never runs. Stacks like Bedrock ship an autoloader that handles this; otherwise add the one-line loader from the README, or copy the plugin file into mu-plugins/ by hand instead. Not both: loading it twice is a fatal error.

The repository is github.com/mantekio/wp-ses-mail. It is the same loop as the last one: the article explains the thinking, the repository is the working plugin, the package is the one-line install, and each points at the other two.

Known limits

Being honest about what a tool does not do is part of the tool. This one has edges worth stating plainly:

It is a transport, not a mailing-list engine. It sends the mail WordPress already wants to send, one message at a time, well. A newsletter blast to tens of thousands of subscribers wants a queue and probably a dedicated bulk sender; leaning on this for that just meets SES throttling as a failed send.
No retry or backoff yet. A send SES refuses fails loudly and stops. It does not queue and try again later. For transactional mail that is usually the right behaviour (you want to know now); if you need durable retries, that is a queue in front of the plugin, not the plugin.
There is a message-size ceiling. SES caps the size of a single message. A mail with very large inline attachments can exceed it, and that send will fail rather than be silently truncated.
Alignment is yours to configure. The plugin signs every message, but DKIM, SPF and DMARC alignment are DNS decisions it cannot make for you. It can tell you they are missing; it cannot add the records.
It needs WordPress 5.7 or newer. The whole clean design rests on pre_wp_mail, which arrived in 5.7. On anything older there is no seam to take: mail falls through to sendmail, and the plugin can warn you but cannot stop it. If you are on a WordPress that old, the mail path is not the first thing to fix.

Sending an email from WordPress is easy. Running mail you can trust for a newsroom, where a lost password reset is a locked-out journalist and a suspended domain is every address on it going quiet, is a different job, and the difference lives entirely in the boring parts. No secret at rest, because there is no secret. A failure you can see, because silence is the bug. A memory of every bounce, because SES keeps score whether or not you do. None of it is clever. All of it is the distance between mail that works on a blog and mail that holds up under a masthead.

That is the whole of how we treat WordPress on AWS: take the seam core gives you, store nothing you would mind leaking, and fail where someone can see it. If your WordPress mail is a mystery you would rather it were not, let's talk.

Lighthouse 100: Custom PHP vs WordPress vs Shopify

Mon, 13 Jul 2026 07:45:45 +0000

?>

Lighthouse 100: Custom PHP vs WordPress vs Shopify

April 2026 12 min read

I’m Jacob Campbell, and a perfect Lighthouse score isn’t luck — it’s the natural result of shipping only the code a page needs. A custom PHP site routinely loads in around 0.6 seconds and scores 100; the same content on a plugin-heavy WordPress or app-laden Shopify theme often lands at three to four seconds. Here’s how Lighthouse actually scores performance, why the platform gap is so wide, and what it takes to reach 100.

Your platform choice is the largest variable. Let’s prove it with hard numbers.

Breaking Down the Numbers – Why Such a Gap?

Malcolm X Is Not a Suffix

Sun, 12 Jul 2026 14:09:14 +0000

Parse Malcolm X with almost any name splitter and you get a suffix. X looks like a roman numeral, roman numerals are suffixes (John III, Henry VIII), so X becomes the suffix and the surname disappears. That's the kind of bug you only find once you already have a working parser, because it isn't a missing rule. It's two correct rules wanting the same token.

Last month I wrote about the casing fix in nameparser: the idea that a parser reading Jane Doe DDS should keep Doe as the surname and DDS as a credential, using letter casing as the signal that lowercasing throws away. Version 1.3.0 is the follow-up, and it is almost entirely about collisions like Malcolm X: tokens that two disambiguation rules both claim. nameparser is a maintained fork of the dormant theiconic/name-parser, by way of codebyzach/name-parser's PHP 8.3+ modernization; the contribution here is the casing and credential layer plus a confidence pass, not the parser core.

The credential that is also a name

JO ANDERSON PhD used to parse to first name J. Jo is a real short given name, but in all caps it also reads as a credential-run token, and the credential rule won. 1.3.0 keeps all-caps short given names intact beside a mixed-case salutation or credential, so Jo survives.

The mirror image is the credential that gets read as a surname. Jane DDS (a credential-only row with no comma) and John A. MD (an initial plus a credential) used to rewrite the trailing credential as the last name, because a token in the surname slot with nothing after it looks like a surname. Both now keep the credential in the suffix.

The collision gets worse with more than one credential. John Smith MD FACS used to keep MD and leak FACS into the name, because FACS is not in the dictionary and an unknown trailing token defaults to a name. Now a known credential anchors the tail and pulls the unknown one in with it, so both stay in the suffix. Parenthetical credentials were their own trap: Jane Doe (MD) used to parse (MD) as a nickname, since parentheses mark nicknames, and now reads it as a suffix. And a credential-only segment that lands before the given name, as in Smith, MD, John, is pulled out to the suffix so the first name stays John rather than becoming MD.

Casing is the tiebreaker for all of these, which means it fails exactly where casing carries no signal. Uniform all-caps registry data, or all-lowercase input, has nothing to disambiguate on, so an ambiguous trailing token defaults to being read as a credential. That's a hard limitation, not a bug, and it's why the library ships a confidence pass: getConfidence() flags a casing-undecidable row as ambiguous so it can go to a human instead of silently into your database wrong.

Word order that hides the surname

Surname-first input is its own minefield when a salutation and a credential sit on the same name. Dr. Kim Jong Un used to lose the surname to the title; Kim Jong Un, MD used to fall back to Western order. Both now keep surname Kim, and Dr. Kim Jong Un, MD correctly yields surname Kim, salutation Dr., and credential MD. The salutation and the credential were each pulling the parser back toward a different word order, and the fix is teaching it that a leading salutation and a trailing credential-only comma tail can coexist with a surname-first name.

The comma inside the nickname

A comma in a name usually means surname-first. So a comma inside a delimited nickname is a direct collision with the rule that reads commas as name-order markers. John (Bob, Jr) Doe and John 'Bob, Jr' Doe used to bisect on that inner comma and lose half the name. 1.3.0 keeps the nickname Bob, Jr whole, for bracketed, quoted, and custom multi-character delimiter pairs alike, and the same holds on the given-name side: Smith, John (Jack, Robert) keeps Jack, Robert intact.

Scripts with no casing at all

If casing is the signal, a script without upper and lower case has none. Wang, 李明 used to split 李明 into two initials, because the initials rule fires on short tokens and nothing told it these were not initials. 1.3.0 leaves caseless-script names intact as the first name. In the other direction, an elided surname particle like the one in 't Hooft used to read as an unterminated nickname or an initial; it now survives as the leading particle. Dutch honorifics (Dhr., Mevr., Mw.) also join the default salutation set, so Dhr. Jan de Vries reads the title as a salutation rather than a first name.

And the input that is trying to break you

A name parser sits directly on user-supplied strings, so an adversarial input is a real exposure, not a theoretical one. Kilobytes of unmatched quotes, 100 KB tokens of any case shape, megabyte-long rows: 1.3.0 parses all of them in linear time and bounded memory. Invalid-UTF-8 delimiter keys and empty whitespace sets that used to emit a compile warning on every parse are now ignored quietly.

Turning a wrong split into a review queue

Every collision above resolves on casing, and casing runs out of signal on uniform-case data. So the honest design isn't to pretend the parser is always right; it's to say when it's guessing. The confidence pass reads the same input the parser does and flags a row whose split hinges on a signal that is not there.

use Iliaal\NameParser\Parser;

$name = (new Parser())->parse('SMITH, JM');
$name->getConfidence();   // ['ambiguous' => true, 'notes' => [...]]
$name->getSource();       // 'SMITH, JM'  (the normalized input it judged)

SMITH, JM is exactly the case with no answer: with mixed case, Smith, JM splits JM into the initials J and M, because the mixed-case surname proves those are initials; all-caps SMITH, JM keeps Jm as a first name, because the caps could equally be a short given name. The parser has to pick one, and the confidence flag records that it had to. getSource(), new in 1.3.0, returns the normalized string the confidence was assessed against, so a batch importer can log precisely what it judged. The flag is advisory and opt-in; it never changes what parse() returns. On a million-row import, that is the difference between silently corrupting an unknown fraction of records and routing a known set of them to a person.

One caution the README states and this post repeats: ambiguous => false on an all-caps row is not a correctness guarantee. Clean credentials that are not also names (RN, PT, OD) are left unflagged on purpose, to keep review volume manageable, so a false there means "no name-colliding token," not "definitely right."

The seams where cases meet

None of these are new features. They're the boundaries between rules that were already there, the places where two disambiguation heuristics both reach for the same token. That's what this round of work looks like: not more cases, but the seams where cases meet. Casing decides most of them. Where it cannot, the confidence flag says so, and the row goes to review instead of into your data wrong.

composer require iliaal/nameparser

github.com/iliaal/nameparser

Schema Markup: The Hidden SEO Weapon

Sun, 12 Jul 2026 07:45:45 +0000

?>

Schema Markup: The Hidden SEO Weapon Most Sites Ignore

March 2026 14 min read

I’m Jacob Campbell, and if I had to name the most underused SEO tactic, it’s schema markup. Most sites never add it, which is exactly why it’s a quiet competitive edge: the same ranking, but a richer, more clickable listing. Structured data tells Google what your content is so it can show stars, FAQs and prices right in the results. Here’s why it works and how to start — with Google’s own numbers.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "BuiltToWinWeb",
  "image": "https://built2winweb.com/logo.webp",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "7322 Ashley Shores Circle",
    "addressLocality": "Lake Worth",
    "addressRegion": "FL",
    "postalCode": "33467",
    "addressCountry": "US"
  },
  "telephone": "+15613017130",
  "openingHours": "Mo-Fr 09:00-17:00",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.9",
    "reviewCount": "7"
  },
  "priceRange": "$$"
}
</script>

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "How much does a custom PHP website cost?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "BuiltToWinWeb offers three flat‑fee packages: Business Pro Website at $1,750, Ecommerce Website at $5,600, and SaaS/Web Application at $10,000."
      }
    },
    {
      "@type": "Question",
      "name": "Why does custom PHP outrank WordPress?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "WordPress loads 847KB of JavaScript on average; custom PHP serves only what's needed. That means LCP scores under 1s vs WordPress’s 3.8s, which directly improves rankings."
      }
    }
  ]
}
</script>

{
  "@type": "Product",
  "name": "Custom Ecommerce Website Development",
  "image": "https://built2winweb.com/ecommerce.webp",
  "description": "Full custom PHP ecommerce store with Stripe checkout. One flat fee, no monthly fees.",
  "offers": {
    "@type": "Offer",
    "price": "5600",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "5.0",
    "reviewCount": "7"
  }
}

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://built2winweb.com/" },
    { "@type": "ListItem", "position": 2, "name": "Services", "item": "https://built2winweb.com/services/" },
    { "@type": "ListItem", "position": 3, "name": "Custom PHP Website", "item": "https://built2winweb.com/services/custom-php-website/" }
  ]
}

{
  "@type": "Article",
  "headline": "Schema Markup: The Hidden SEO Weapon",
  "datePublished": "2026-03-15",
  "author": {
    "@type": "Person",
    "name": "Jacob Campbell"
  },
  "publisher": {
    "@type": "Organization",
    "name": "BuiltToWinWeb",
    "logo": { "@type": "ImageObject", "url": "https://built2winweb.com/logo.webp" }
  },
  "mainEntityOfPage": "https://built2winweb.com/blog/schema-markup"
}

function getProductSchema($product) {
    return [
        "@context" => "https://schema.org",
        "@type" => "Product",
        "name" => $product['name'],
        "description" => $product['description'],
        "offers" => [
            "@type" => "Offer",
            "price" => $product['price'],
            "priceCurrency" => "USD",
            "availability" => $product['in_stock'] ? "https://schema.org/InStock" : "https://schema.org/OutOfStock"
        ]
    ];
}

// Then output as JSON
$schema = getProductSchema($product);
echo '<script type="application/ld+json">' . json_encode($schema, JSON_UNESCAPED_SLASHES) . '</script>';

Failing Closed: What Shipped Across Seven PHP Extensions

Fri, 10 Jul 2026 13:26:46 +0000

ExcelBook::save() to a file:// path used to truncate your existing file before it finished writing the new one. If the write was short or got interrupted, you were left with neither the old file nor a complete new one. php_excel 2.4.0 fixes that: the write goes to a temp file and renames into place, so a failed save leaves your original intact.

That fix doesn't make a good changelog headline. It's also most of what shipped across seven of my PHP extensions in the last month. Some of it is new capability, a new Markdown engine, twelve more chart types, a columnar serializer, native JSON columns in ClickHouse. Most of it is the other kind of work: rejecting a bad value instead of storing it, throwing on the untrusted path instead of trusting it, failing a write cleanly instead of half-committing it. This is the second roundup in the series; the June one covered the version-floor drops. Here is what landed since.

mdparser 0.4.3: a new engine under the same API

mdparser swapped its entire parsing backend in 0.4.0. cmark-gfm is gone, replaced by md4c, a single-file streaming CommonMark parser compiled directly into the extension. The four render methods and the Options surface are unchanged; only the engine underneath is new. The swap brings clean CommonMark 0.31 conformance (652 of 652 spec examples) and drops the external cmark-gfm dependency entirely.

md4c also supports a set of dialects cmark-gfm did not, each opt-in and off by default: LaTeX math ( $inline$ and $block$), wiki links ([[target]]), spoilers, ==highlight==, super and subscript, and GitHub-style admonition blocks (> [!NOTE]) added in 0.4.1. Each surfaces as its own node type in toXml() and toAst().

use MdParser\{Parser, Options};

$html = (new Parser(new Options(latexMath: true, wikiLinks: true)))->toHtml($source);

The hardening that came with the rewrite is the part I care about more. 0.4.2 fixed a stack buffer overflow in the CommonMark XML serializer: an ordered list with a wide start number could truncate the tag, embed a NUL byte, and at the widest input read past a fixed 64-byte stack buffer. 0.4.3 closed an alt="..." breakout where raw HTML in image alt text was not attribute-escaped under unsafe: true. And the in-stream heading-anchor rewrite resolved the 0.3.0 limitation where a raw <h1> and a Markdown # heading could fight over the same id.

One honest trade: md4c exposes no source positions, so sourcepos and a handful of old cmark-only options are accepted for compatibility but inert.

github.com/iliaal/mdparser

fastchart 1.6.0: from 26 chart types to 38

fastchart 1.4.0 added twelve chart classes in one release, taking the catalog from 26 types to 38. The new set is mostly hierarchy and relationship charts: dendrogram, partition (icicle), chord diagram, network graph, arc diagram, circle packing, Venn diagram, violin plot, population pyramid, word cloud, pictogram, and a serpentine timeline. The two hierarchy charts feed from one setHierarchy() call.

$chart = new FastChart\Dendrogram(900, 600);
$chart->setHierarchy($root);
$chart->renderToFile('tree.svg');

1.5.0 was the performance release. A 4096-point scatter with per-point colors renders about 6x faster now that SVG color handles resolve through a hash table instead of a linear scan; renderPng() is about 40% faster after switching from adaptive to a fixed UP row filter at effectively unchanged file size; and dense SVG documents emit about 40% faster through dedicated integer color formatters. 1.4.0 also added seven StockChart indicators (VWAP, ZigZag, ATR, CCI, Williams %R, Aroon, standard deviation).

The vector PDF backend from 1.3.0 is still a v1. This round's PDF work was hardening, fully transparent colors that used to paint opaque, band-gradient alpha that got discarded, rather than the gradient support it still lacks.

github.com/iliaal/fastchart

php_clickhouse 0.10.0: JSON, Bool, and IPv6 columns, and a faster decoder

Three releases since 0.8.7. 0.8.8 added native JSON, Bool, and IPv4/IPv6 column read and write; a JSON insert takes a PHP array, object, or raw JSON string, and reads return the string or decode with JSON_AS_ARRAY / JSON_AS_OBJECT. 0.9.0 rewrote the decoder and insert-builder hot paths. 0.10.0 tightened correctness.

The perf work in 0.9.0 is the kind you only find with a profiler. Result decoding used to downcast each scalar column through dynamic_pointer_cast, an atomic refcount round-trip plus an RTTI walk; a callgrind attributed about 18% of decode instructions to that one cast. The integer, float, and string paths now use a direct static cast keyed on the column's type code. Numeric inserts build straight from the row-major input instead of transposing into a temporary PHP array first. Wide integer SELECTs decode about 25% faster; numeric-heavy inserts land 30 to 44% faster.

// FixedString payloads (IPv6, hash digests) read back at full width, trailing NULs kept
$rows = $ch->select('SELECT ip FROM sessions', [], ClickHouse::FIXEDSTRING_BINARY);

0.10.0's correctness pass is the fail-closed theme again: inserting PHP null into a non-Nullable JSON column now throws instead of silently storing an empty {}, and a clean server error (bad SQL, missing table) no longer reconnects and quietly discards your session's temp tables and SET settings.

github.com/iliaal/php_clickhouse

phpser 0.4.0: a columnar wire format for rowsets

phpser's wire format v2 (0.3.0) added a columnar layout for homogeneous rowsets. Instead of writing each row's keys and values, TAG_TABLE writes the column schema once, then each column as a typed run: packed longs, doubles, strings, or mixed. For the array-of-uniform-rows shape that cache and queue payloads usually are, that drops the per-row key overhead entirely. v1 payloads still decode.

$blob = phpser_serialize($rows);   // columnar automatically when rows share a schema
$rows = phpser_unserialize($blob);

0.4.0 made table encode a single row-major pass instead of an O(rows × cols²) per-column rescan (about 20% faster rowset encode on aarch64), and rowset decode about 24% faster by resolving dictionary strings against the engine's interned-string table. It also closed two issues on the untrusted decode path. A TAG_OBJECT_SLOTS payload now routes through __unserialize() when the class defines it, instead of installing raw property slots and running __wakeup(), closing an invariant-rebuild bypass. And a crafted __PHP_Incomplete_Class_Name property can no longer resurrect an attacker-chosen class name on a later decode.

The columnar path is automatic; you don't opt in. It only engages for homogeneous string-keyed rowsets, and a single row or a mismatched schema falls back to the general encoding.

github.com/iliaal/phpser

fastjson 0.6.0: JSON Pointer you can write to, and prebuilt binaries

The June roundup covered fastjson_pointer_get() and merge-patch. 0.5.0 completed the RFC 6901 surface with fastjson_pointer_set(), which sets a value by pointer and returns the re-serialized document, and fastjson_pointer_exists(), which distinguishes present-but-null from absent without materializing anything into PHP.

$updated = fastjson_pointer_set($json, '/user/email', '*Emails are not allowed*');

0.5.0 also started publishing prebuilt .so binaries for Linux glibc (x86_64, arm64) and macOS (arm64) on PHP 8.4 and 8.5 as release assets, so PIE installs the binary instead of source-building on those targets. 0.6.0 was hardening: a use-after-free when encoding an array that a nested JsonSerializable mutates through an aliasing reference (the array is now copied first, as ext/json does), and stack-exhausting nesting in pointer_set rejected up front instead of crashing.

github.com/iliaal/fastjson

php_excel 2.4.0: bulk reads and a hardening pass

2.3.0 added bulk read paths. readRange() pulls a rectangular block of cells into a 2D array in one call instead of per-cell PHP dispatch, readSparseRow() and readSparseCol() return only the occupied cells keyed by their original index, and loadPartially() reads a single sheet's row slice without loading the rest of the workbook.

$block = $sheet->readRange(0, 999, 0, 25);   // a 1000 x 26 region in one call

2.4.0 is the atomic-save fix from the top of this post plus the rest of the fail-closed pass: load() rejects a buffer above UINT_MAX instead of truncating a payload over 4 GiB, writeRow() and writeCol() validate every value before writing any cell instead of committing half the row and then failing, and inverted ranges (first > last) are rejected instead of stored as garbage coordinates. One security tightening: excel.license_key and excel.license_name are now PHP_INI_SYSTEM, so a per-request ini_set() or .user.ini can no longer overwrite the commercial license in a shared pool.

github.com/iliaal/php_excel

fast_uuid 0.4.0: binary and batch generators, and ramsey/uuid parity

0.3.0 added binary and batch generation. The binary generators (uuid_v4_bin(), uuid_v7_bin(), and the rest) return the raw 16 bytes with no canonical formatting, for a BINARY(16) column or a wire format with no string round-trip. The batch generators build many at once and amortize the per-call cost; v7 batches stay monotonic within the call.

$ids = uuid_v7_bin_batch(1000);   // 1000 raw 16-byte v7 UUIDs, monotonic

Most of 0.3.0 and 0.4.0, though, is ramsey/uuid compatibility correctness. The compat TimestampFirstCombCodec used a byte rotation instead of ramsey/uuid's first-6/last-6 swap, so a COMB written by ramsey/uuid decoded to a different UUID; the layout now matches, and COMB columns interop. Fields::getTimestamp() truncated v1 and v6 timestamps on 32-bit PHP; it now rebuilds them exactly as a hex string. Canonical parsing also runs about twice as fast through a 256-entry nibble lookup table.

One breaking change to note if you catch it: UnsupportedOperationException now extends \LogicException instead of \RuntimeException, matching ramsey/uuid 4.x.

github.com/iliaal/fast_uuid

The unglamorous majority

The features are the headline: a new Markdown engine, twelve more chart types, a columnar serializer, native JSON in ClickHouse. But count the lines in these seven changelogs and most of them are the other kind: a value rejected instead of stored, a write that fails cleanly instead of half-committing, a throw on the untrusted path instead of a silent coercion. That work never reads well in release notes. It's the difference between an extension you benchmark once and one you leave running.

How to Add Stripe Checkout to a Custom PHP Website (No Plugins)

Fri, 10 Jul 2026 07:45:45 +0000

How to Add Stripe Checkout to a Custom PHP Website (No Plugins)

September 2025 14 min read by Jacob Campbell

I’m Jacob Campbell, and you don’t need WooCommerce or a pile of plugins to take payments — plain PHP and Stripe Checkout do it cleanly. Stripe hosts the secure payment page, handles card validation and 100+ payment methods, and hands you back a verified result. Your PHP just creates a session and listens for a webhook. Here’s how the flow works end to end and why the no-plugin approach is leaner and safer.

Platform Comparison — Custom PHP vs Shopify vs WooCommerce

Frequently Asked Questions

Can I take payments in PHP without WooCommerce?

Yes. Stripe Checkout needs only the Stripe PHP library: create a Checkout Session, redirect to Stripe’s hosted page, and confirm via webhook.

What is a Checkout Session?

A server-created object that returns a URL to Stripe’s hosted payment page, where Stripe securely collects and validates the payment.

Why use webhooks for fulfilment?

Because customers can close the tab before the redirect. The checkout.session.completed webhook reliably confirms payment regardless of what the browser does.

Is a no-plugin checkout secure?

Yes — Stripe hosts the card entry and you verify webhook signatures. There is less code and a smaller attack surface than a full e-commerce plugin.

Does Stripe Checkout support subscriptions?

Yes. Set the session mode to subscription to take recurring payments with the same hosted flow.

Migrate WordPress to Custom PHP Without Losing SEO

Thu, 09 Jul 2026 07:45:45 +0000

Migrate WordPress to Custom PHP Without Losing SEO

December 2025 16 min read

I’m Jacob Campbell, and I move sites off WordPress for a living without losing rankings — here’s the technical playbook. WordPress is fine until the plugin weight, security patching and speed become a tax you pay forever. Custom PHP removes that tax, and if you migrate carefully, Google never notices the switch. This is the step-by-step from export to launch, grounded in Google’s own site-move guidance.

Error, loss functions, and why they are needed

Wed, 08 Jul 2026 10:34:00 +0000

2.1 Error, loss functions, and why they are needed

Error, Loss Functions, and Why We Need Them

Any machine learning model comes down to a simple idea: it tries to describe reality using some function. That means there will always be a mismatch between what actually exists and what the model predicts. We call this mismatch an error.

It is important to understand one key thing: the model does not know what is "good" or "bad". It does not understand the meaning of the task. During training, all it does is try to reduce a special number calculated from its errors. This number is called the loss function.

Formally, error is the deviation between the real value $y$ and the model prediction $\hat{y}$, while loss is a function that converts this deviation into a number convenient for optimization – a number the model tries to minimize during training.

Imagine a simple example. Suppose a model has to predict the price of an apartment.

Actual price: y = 200 000
Model prediction: ŷ = 180 000

The model made a mistake. The only question is how exactly we measure this error.

Error as Distance

Suppose we have a real value $y$ and a model prediction $\hat{y}$. The most natural thing to do is to look at the difference:

\[ error = y - \hat{y} \]

But this value by itself is inconvenient for training a model. It can be both negative and positive. If we have many observations, positive and negative errors can cancel each other out.

For example:

+10
-10

The average error would be zero, even though the model is clearly making mistakes.

That is why we introduce a loss function – a function that transforms the error into a non-negative number suitable for optimization. This is the number the model tries to minimize during training.

Geometrically, it looks like this: we measure how far the prediction is from the real value on the number line.

Figure 2.1-1. The distance between y and ŷ on the number line

Essentially, we want to convert the deviation into a number that behaves like a distance. Let us explain why. In regression tasks, it is convenient to interpret error as the distance between the real value and the prediction – that is, a number that is always non-negative and grows as the error increases.

However, not every loss function is a distance in the strict mathematical sense:

In MSE – yes, it is the squared Euclidean distance between the prediction and the real value
In log loss (logarithmic loss) – it is no longer a metric distance but a divergence

This immediately leads us to an important idea: error should be non-negative.

Squared Error as a Penalty for Missing the Target

The simplest way to get rid of the sign is to take the absolute value of the error.

\[ L = |y - ŷ| \]

But the absolute value is not differentiable at point 0, which complicates optimization. That is why ML usually uses squared error instead:

\[ L = (y - \hat{y})^2 \]

Why?

First, squaring makes the function smooth and differentiable everywhere, which is critically important for gradient optimization and makes model training easier.

Second, squaring strongly amplifies large errors.

If the error increases by a factor of 2, the penalty increases by a factor of 4:

\[ (2e)^2 = 4e^2 \]

For example:

Error   →    Squared error
-----------------------------
 1                   1
 2                   4
 5                  25
10                 100

Because of this property, MSE is especially sensitive to large errors and outliers.

This is an important feature: we tell the model in advance that rare but large mistakes are worse than many small ones.

Mean Squared Error (MSE)

If we have many observations, we calculate the squared error for each of them and then average the results:

\[ \text{MSE} = \frac{1}{n} \sum\_{i=1}^{n} (y\_i - \hat{y}\_i)^2 \]

From a geometric point of view, MSE is the average squared distance between real values and predictions – in other words, the squared vertical deviations of points from the model.

If we imagine the data as points on a plane and the model as a line or surface, MSE measures how far the points are from that surface.

Figure 2.1-2. Data points and regression line, vertical bars are errors

A Bit of Useful Math

Why is MSE used so often? Because the minimum of MSE behaves very predictably.

If the model is linear:

\[ \hat{y} = wx + b \]

then MSE as a function of parameters $w$ and $b$ is convex with respect to the model parameters.

This means:

it has one global minimum
the anti-gradient (the direction opposite to the gradient) points toward reducing the error function
training is stable

Figure 2.1-3. Graph of a convex loss function with a single minimum

This is one of the reasons why linear regression is such a fundamental and reliable tool.

The Connection Between MSE and the Normal Distribution

There is another important but often implicit fact. Minimizing MSE is equivalent to maximizing likelihood if we assume the errors are normally distributed:

\[ \varepsilon = (y - \hat{y}) \sim \mathcal{N}(0, \sigma^2) \]

In this case, minimizing MSE is equivalent to maximizing likelihood.

In other words, MSE is not just a convenient formula. By using it, we implicitly assume that the noise $\varepsilon$ follows a normal distribution – the familiar "Gaussian bell curve".

Why MSE Is Not Suitable for Classification

So far we have discussed regression tasks, where the model predicts a numerical value. But there is another type of task – classification – where the model has to choose one of several possible answers.

Imagine a binary classification problem with two possible outputs: "yes" and "no". For example, spam or not spam.

Real value:

\[ y \in {0,1} \]

Model prediction:

\[ \hat{p} \in \[0, 1] \]

If we use MSE, the difference between probabilities 0.99 and 0.51 does not appear very large, even though intuitively these predictions are of completely different quality when the correct answer is 1 (that is, spam).

In general, MSE does a poor job distinguishing confidence levels and does not match the probabilistic nature of the problem.

What matters is not only whether the model guessed correctly, but also how confident it is in its answer.

Log Loss as the Cost of Confidence

Log loss solves exactly this problem. The idea behind this function is very simple: it heavily penalizes the model when it is confidently wrong.

Suppose the correct answer is 1 (spam), meaning $y = 1$.

If the model predicts:

p = 0.9 → small error
p = 0.6 → larger error
p = 0.01 → enormous error

In other words, the more confidently the model is wrong, the stronger the penalty should be.

This idea is mathematically expressed by the log loss function.

For a single observation:

\[ LogLoss = - \left( y \log(\hat{p}) + (1 - y) \log(1 - \hat{p}) \right) \]

If $y = 1$, only this term remains:

\[ -\log(\hat{p}) \]

Let us look at a few examples.

Probability  →    Loss
-----------------------
0.9               0.105
0.6               0.51
0.01              4.6

As we can see, being confidently wrong is extremely expensive.

In practice, the model makes predictions for many observations at once. Therefore, the total loss function is the average log loss across all observations:

\[ LogLoss = -\frac{1}{n} \sum\_{i=1}^{n} \left(y\_i \log(\hat{p}\_i) + (1 - y\_i) \log(1 - \hat{p}\_i)\right) \]

Consider a simple example with three observations.

y         p̂         loss
-------------------------
1        0.9        0.105
0        0.2        0.223
1        0.6        0.511

The average log loss will be:

\[ \frac{0.105 + 0.223 + 0.511}{3} \approx 0.28 \]

This is the value the model tries to minimize during training.

Now let us look at the graph of this function – it is very revealing.

Figure 2.1-4. Plot of -log(p) as p → 0 and p → 1

when $\hat{p} \to 1$, the error approaches zero
when $\hat{p} \to 0$, the error approaches infinity

This is the mathematical expression of the idea:

Being confidently wrong is almost a crime.

The Geometric Meaning of Log Loss

Log loss can be interpreted as a measure of divergence between the real distribution and the predicted probability distribution.

Formally, it is a special case of cross-entropy:

\[ H(p, q) = - \sum p \log(q) \]

Where:

$p$ – the true distribution
$q$ – the model distribution

Figure 2.1-5. Two probability distributions and the distance between them

This makes log loss a natural choice for probabilistic models.

Intuitive Comparison Between MSE and Log Loss

MSE asks:

How far off were we in value?

Log loss asks:

How wrong were we in our confidence?

That is why the following practical rule works well in most real-world cases:

regression → MSE
classification → log loss

Final Thought

A loss function is the language we use to communicate with the model. Through it, we explain what we consider an error, which mistakes are especially bad, and which ones are acceptable.

The model knows nothing about money, spam, or the meaning of text. It only knows one thing: where to move in order to reduce the loss.

In the next chapter, we will see how minimizing loss turns into a concrete learning algorithm – through gradients and parameter updates.

I objected to deprecating metaphone(). Then I read the RFC.

Wed, 01 Jul 2026 13:56:49 +0000

A while back a proposal landed on the PHP internals list: deprecate metaphone(). My first reaction was the reflex of someone who has spent years as a PHP release master. Leave the old string functions alone, people depend on them, deprecation churn is its own tax. I was ready to argue against it.

Then I read the reasoning and went looking at what phonetic name matching is actually supposed to do in 2026. I changed my mind. metaphone() should go. What surprised me was not that the function is dated. It was how far the field had moved while PHP core stood still, and how weak the replacement path the RFC points at really is. So I built the replacement I wish it had recommended.

metaphone() is the oldest, least accurate version of an idea that kept evolving

The RFC is right, and here is the short version of why. The metaphone() in core is the original 1990 algorithm: English-only, single-key, tuned for one accent of one language. It was superseded twice. First by Double Metaphone (Lawrence Philips, 2000), which emits a primary and an alternate key so ambiguous pronunciations still match. Then by Metaphone 3, which corrects hundreds more edge cases.

Core shipped the first version and never moved. soundex() is older still, a 1918 patent. Both encode a single English-centric key, and both fall over the moment a name crosses a language boundary or carries a transliteration variant. For the one job these functions exist to do, collapsing names that sound alike but are spelled differently, they are the weakest tools in the drawer.

So the deprecation is defensible. Maintaining the least accurate member of a whole family of algorithms, in C, in core, when most applications can do better elsewhere, is not a good use of anyone's time. I came around to that part.

"Use a userland library" is the wrong replacement

Here is where I part ways with the RFC. Its answer to "what do I use instead" is that there are actively maintained Composer libraries implementing Double Metaphone. That is true, and it is also the wrong instinct.

Phonetic encoding is a hot inner-loop operation. You run it over every name in a dataset, sometimes millions of them, to build a match index you can query later. A pure-PHP implementation pays interpreter overhead on every character of every name. The honest replacement for a native C string function is another native C string function, not a userland reimplementation that is correct but an order of magnitude slower. That performance gap is the entire reason the code lived in core to begin with.

That is what moved me from "argue against the RFC" to "agree with the RFC, then go build the thing it should have recommended." The result is phonetic, a native extension that ships the five encoders core never had, plus the comparison helpers that answer the only question most people actually ask.

Double Metaphone: the successor you can actually ship

Double Metaphone is the algorithm the RFC's own rationale reaches for first, and it is the natural default. It returns two keys, a primary and an alternate, so a name with more than one plausible pronunciation matches on either.

double_metaphone("Schwarzenegger");   // ['primary' => 'XRSN', 'alternate' => 'XFRT']
double_metaphone("Catherine", 3);     // ['primary' => 'K0R',  'alternate' => 'KTR']

The RFC names Metaphone 3 as the other successor. Worth knowing before you reach for it: the Metaphone 3 reference implementation is a commercial product, sold as source for $240, not free software. An older 2009 build sits under a BSD license inside OpenRefine, minus years of accuracy corrections. Double Metaphone is the newest variant you can actually vendor into an open project, which is why it, and not Metaphone 3, is what belongs within reach of every PHP app. My implementation is clean-room from the published algorithm, with Apache Commons Codec used only as a parity oracle for the test vectors.

Beider-Morse: matching across languages, and the GPL trap I had to dodge

Moskowitz and Moskovitz are one surname through two transliterations. A Cyrillic name like the Russian Ivanov is one most encoders will not touch. Beider-Morse Phonetic Matching handles both, because it is language-aware. It detects, or is told, the source language family, then applies the right transliteration rules for Slavic, Germanic, Hebrew, and Romance names.

bmpm("Garcia", BMPM_SEPHARDIC, BMPM_EXACT);   // "garsia|gartSa"
bmpm_match("Moskowitz", "Moskovitz");          // true

The hard part is not the code, it is the data. BMPM is thousands of rules, and every obvious source for those rules is GPL. The canonical Beider-Morse PHP reference is GPL-3.0. abydos, the popular Python phonetic library, is GPL-3.0 specifically because it ported that same rule data. Copy either into a BSD project and the whole project turns GPL with it.

The escape is Apache Commons Codec, which ships the identical rule tables under Apache-2.0. I vendored the data from there, kept its license header, and added an Apache-2.0 section to the extension's LICENSE. Same data, clean license, and Commons Codec doubles as the parity oracle, so I know the output matches the de-facto reference. The lesson generalizes past this one extension: with phonetic algorithms, the data carries the license, not the code you wrap around it.

One honest caveat. BMPM is slow. It runs language detection and three rule passes over the input, so it costs roughly 60 times a Double Metaphone call, around 91,000 names a second on my machine. You pick it for recall, not throughput. When you already know the language, passing it explicitly skips detection and buys some of that back.

Daitch-Mokotoff Soundex: the genealogy standard

If you are matching Eastern-European or Ashkenazi surnames, this is the field standard, and core never had it. Daitch-Mokotoff was built for exactly that problem, and it is what genealogy databases actually run. It emits a set of six-digit codes, branching on ambiguous letters so one name can carry several codes at once.

dm_soundex("Auerbach");                     // ['097400', '097500']
dm_soundex_match("Moskowitz", "Moskovitz"); // true

Its rule data comes from Apache Commons Codec too, for the same licensing reason as BMPM.

NYSIIS and Match Rating: two lighter English encoders

Both are cheap single-key encoders for American and English names, useful as a second opinion or an alternate index key. NYSIIS (New York State Identification and Intelligence System) is tuned for American surnames and returns one key. Match Rating Approach (Western Airlines, 1977) produces a compact codex and, unusually, ships its own similarity test instead of relying on key equality.

nysiis("Larson");            // "LARSAN"
nysiis("Larsen");            // "LARSAN"  (same key)
match_rating("Catherine");   // "CTHRN"

Both are clean-room from their published specs. They are the fastest encoders in the set, cheap enough to run as a second key alongside Double Metaphone when you want a little more recall without paying BMPM's cost.

The part I use most: the comparison helpers

The real day-to-day question is never "encode this name." It is "do these two names sound alike," and every algorithm answers it differently. That difference is where userland code quietly gets phonetic matching wrong.

Double Metaphone gives two keys; you match on primary agreement, weaker if only an alternate crosses. Daitch-Mokotoff and BMPM give sets; you match on intersection, not equality. Match Rating has a length-and-rating threshold that plain codex comparison skips entirely. Get that logic wrong and you either miss real matches or wave through garbage. So the extension ships one comparison helper per algorithm, each encoding the correct test for that encoder:

double_metaphone_match("Catherine", "Kathryn");   // 2  (primary keys agree)
double_metaphone_match("Vagner", "Wagner");        // 1  (only an alternate crosses)
dm_soundex_match("Moskowitz", "Moskovitz");        // true
bmpm_match("Peterson", "Petersen");                // true
nysiis_match("Smith", "Schmit");                   // true  (both SNAT)
match_rating_compare("Catherine", "Kathryn");      // true

double_metaphone_match() returns 2, 1, or 0, so you can rank match strength instead of treating it as a coin flip. The set-based helpers return a bool on intersection. match_rating_compare() applies the threshold the algorithm actually specifies. You call one function and get the right answer for that encoder, rather than reimplementing set intersection in a loop and getting the edge cases subtly wrong.

For a one-off check, that is the whole API. For repeated lookups against a fixed corpus, encode once and index the keys, then query by encoded value instead of comparing pair by pair:

$index = [];
foreach ($records as $id => $name) {
    foreach (dm_soundex($name) as $code) {   // index every code in the set
        $index[$code][] = $id;
    }
}
$hits = $index[dm_soundex("Moskovitz")[0]] ?? [];

Which one do I reach for?

Double Metaphone as the fast general-purpose default. BMPM when names cross languages or scripts and you can afford the cost. Daitch-Mokotoff for Eastern-European and Jewish genealogy, where it is the standard. NYSIIS or Match Rating as a cheap second key. The relative costs matter when you are encoding at scale:

encoder	relative speed	strongest for
`match_rating()`	fastest (0.24x)	English names; ships its own similarity test
`nysiis()`	fast (0.42x)	American and English surnames
`double_metaphone()`	fast (1.0x baseline)	general Latin-script names
`dm_soundex()`	middle (~2.3x)	Eastern-European and Ashkenazi surnames
`bmpm()`	slowest (~60x)	cross-language and transliteration variants

Two limits worth stating plainly. These are heuristic, culture-bound encoders. They target Latin-script names, and for BMPM and Daitch-Mokotoff, specific language families. They are not a universal global-name solution. And Greek-script input has a known limitation: capitals are not lowercased, because the context-sensitive final-sigma rule cannot be expressed as a point-wise case map, so Greek names need to be passed lowercased or romanized.

Where I landed

I set out to defend metaphone() and finished by agreeing it should be deprecated. The function is the weakest version of an idea that produced far better tools over the thirty years since. The flaw in the deprecation story is not the deprecation. It is pointing at a slower userland library as the replacement for a native one. Phonetic encoding runs in a hot loop, so it belongs in C.

The five encoders core never shipped are now one native extension, with the "do these sound alike" helpers most callers actually need:

pie install iliaal/phonetic

github.com/iliaal/phonetic

Coder Legion - Recent posts tagged php

PHP2Shell: When a Simple Upload Feature Turns Into Remote Code Execution

Introduction

1. First, what exactly is PHP2Shell?

2. The interesting part: PHP Upload Progress

3. Understanding the actual memory-management bug

4. Understanding the two vulnerabilities

5. My practical investigation on TryHackMe

6. Observing the memory disclosure

7. From memory disclosure to remote code execution

8. Detection and mitigation

9. What I learned from this investigation

Final thoughts

PHP2Shell: patch PHP now, then check

What changed

Who it applies to

What to do today

Interim mitigations PHP published

A free scanner, and its catch

Questions people ask

Sources

WordPress Crash Recovery & Plugin Conflict Resolution

Common Crash Failure Modes After Updates

Systematic Diagnostic Protocol

Step 1: Capture Raw Error Logs Without Exposing Stack Traces

Step 2: Safe Plugin Isolation via WP-CLI

Step 3: Check MySQL Database Integrity and Migration Locks

Step 4: Patch Compatibility or Pin Version

Step 5: Verification and Regression Testing

When to Seek Engineering Assistance

php2shell: two ways PHP corrupts its own memory, and why turning that into a shell is still hard

If you read nothing else, do these five things

Credit where it is due

Why this wasn't Log4Shell

The root cause: PHP panics by longjmp, and panic skips cleanup

The primitive: one signed integer turns a session into an arbitrary write

From one write to a shell: the four-request mod_php chain

Reading the layout from the wire: the Set-Cookie oracle

Six paths, two execution models, one scorecard

Why FPM is the harder target

The barrier the PoCs skip: every stage needs the same worker

Every number is build-specific

Mitigations, mapped to what they actually buy you

How this was done, honestly

What this bug is, and what it isn't

Corrections welcome

Seventeen Seconds to Parse One Name: A Security Scan Across Eleven PHP Projects

What the scans found, and what is fixed

Bugs that needed no attacker

Bugs a server, a file, or a document could trigger

The other high and medium findings

memory_limit stopped stopping things

The re-release day

Refusing vulnerable PHP releases

pdo_duckdb 0.9.0: DuckDB 2.0

Performance, with the hardware attached

Breaking changes worth reading before you upgrade

What a scan is worth

What SafeLine's PHP Core Rule Actually Watches in the Request

Does the rule fire on every multipart post?

What should a useful hit contain?

Can I skip observe mode if I trust the signature?

What to Inspect After a PHP Core Rule Hit

What is the minimum record to keep?

Should every hit trigger a credential rotation?

Does blocking replace the PHP upgrade?

How to Inventory Every PHP Version Before You Call the Estate Patched

How do I know which version a vhost uses?

Can one SafeLine rule cover every old branch?

What belongs in the "cannot upgrade" note?

Why Multipart Uploads Need a Separate Look After CVE-2026-109618

Is every upload form affected?

Will observe mode stop the exploit?

What should be upgraded first?

Finding the slow part of a WooCommerce page with Query Monitor

Install it on staging first

Read the queries by component

Check outgoing HTTP calls

Time your own code

Look at a page as a guest