标签：#HP

Performance work has a reputation for being glamorous — the heroic "we cut latency by 80%" story. Most days it's not that. Most days it's a janitorial pass: you go looking for the queries you're firing without realizing it, and you quietly delete them. That was today. One sustained sweep across an app and the package that backs it, chasing the same theme everywhere: stop asking the database for things you don't use. Let me walk through the patterns, because they generalize to any Laravel app of a certain age. First, make the invisible visible You can't fix N+1s you can't see. The first move was wiring up an N+1 detector in the local/dev environment only — beyondcode/laravel-query-detector . It hooks into the request lifecycle, watches your Eloquent relationship loads, and screams (in the console, or as an exception if you want it strict) when it spots the classic loop-and-lazy-load pattern. The "dev-only" part matters. You never want a query detector running in production — it adds overhead and it's a developer aid, not a runtime guard. So it goes in behind an environment check, registered only when the app isn't in production: public function register (): void { if ( $this -> app -> environment ( 'local' , 'testing' )) { $this -> app -> register ( \BeyondCode\QueryDetector\QueryDetectorServiceProvider :: class ); } } Think of it like a smoke detector you only arm while you're cooking. It's noisy by design — that's the point. The noise is a to-do list. Eager loads you don't actually use are just N+1s wearing a disguise Here's the counterintuitive one. We're all trained to fix N+1s by adding with() . But the opposite bug is just as common and almost never gets caught: you eager-load a relationship, and then... never touch it in the view. Index screens are the worst offenders. Someone builds a listing, eager-loads creator and approver so the table can show names, then a redesign drops those columns — but the with(['creator', 'approver']) stays. Now every page load hyd

You open the "Updates" page in WordPress admin and see that Elementor Pro / ACF Pro / vk-blocks-pro have updates available. Then you run wp plugin update --all from your automation, and those exact plugins don't update. The asymmetry — "the admin sees it; WP-CLI doesn't" — traces back to how WordPress detects updates and how premium plugins layer proprietary update mechanisms on top of that. Here's the mechanism and how an automation tool can adapt. WordPress update detection is held by a transient cache WordPress doesn't decide "is there an update?" on every request. It caches the answer in the wp_options table as a transient, valid for up to 12 hours. The key entries: _site_transient_update_plugins — latest plugin versions _site_transient_update_themes — themes _site_transient_update_core — core If those transients are stale, even a version that just shipped on wordpress.org reads as "no update needed." WP-CLI consults the same transients, so stale cache = WP-CLI misses the update too . In one customer environment on ConoHa WING, we reproduced "version X is on wordpress.org, WP-CLI doesn't see it" directly. Trap 1 and fix 1 — force-refresh the transients before listing updates The first step was simple: at the start of a maintenance run, delete the three transients before querying the update list . def _flush_update_transients ( self , conn , wp_cmd , wp_path , site_name ): """ Delete update transients between DB backup and update step """ for t in ( " update_plugins " , " update_themes " , " update_core " ): conn . run ( f " { wp_cmd } transient delete { t } --path= { wp_path } " , warn = True , hide = True , ) Deleting the transients triggers a rebuild on the next wp plugin list --update=available . During the rebuild, WordPress reaches out to wordpress.org, so the returned list reflects the current release state . That handled the "we were just reading a stale cache" cases. But it didn't help with premium plugins. Trap 2 — with --skip-plugins , Pro updater filt

nvidia-peermem "Invalid argument" on Ubuntu — Fix GPUDirect RDMA with DMA-BUF TL;DR: If modprobe nvidia-peermem fails with Invalid argument ( -EINVAL ) on a system using the inbox Ubuntu InfiniBand stack ( rdma-core ), the module is not broken and you do not need it. nvidia-peermem requires an API that only exists in MLNX_OFED. On Hopper/Blackwell GPUs with the NVIDIA open driver, use DMA-BUF instead — it does GPUDirect RDMA natively. The one gotcha: you must enable nvidia-drm modeset=1 . Applies to: Ubuntu 22.04 / 24.04, inbox rdma-core stack, NVIDIA open kernel driver, H100 / H200 / B200, ConnectX-6/7 (or any HCA with ODP support). The symptom $ sudo modprobe nvidia-peermem modprobe: ERROR: could not insert 'nvidia_peermem' : Invalid argument dmesg shows nvidia-peermem loaded but registered nothing, or the load returns -EINVAL . GPUDirect RDMA appears to be unavailable. Why this happens (and why it is not a bug) nvidia-peermem is the legacy path for GPUDirect RDMA. It registers GPU memory with the InfiniBand subsystem through a Mellanox-proprietary kernel API: ib_register_peer_memory_client () That symbol only exists in MLNX_OFED's build of ib_core . It is not in the mainline kernel, and it is not in rdma-core , which is the inbox InfiniBand stack on Ubuntu. If you are on the inbox stack, nvidia-peermem was compiled without that API present, so it can never bind and always returns Invalid argument . No module parameter or config change will fix it, because the thing it needs was never there. Do not install MLNX_OFED just to make nvidia-peermem load. That works, but it is the wrong fix — you would be adding a heavy proprietary stack to revive an obsolete module. There is a native path already in your kernel. The fix: use DMA-BUF On Hopper and newer with the open driver, GPUDirect RDMA works through DMA-BUF , a mainline Linux framework. No external module, no MLNX_OFED. Requirements (check these first) NVIDIA open kernel driver (not the proprietary build) nvidia-drm

I expected bcrypt to silently drop characters past 72. I did not expect it to bake in half an emoji. That's what happens with a specific password combination I tested. The original password still works. But strip the emoji (a password manager, a different keyboard, a Unicode normalizer) and you're locked out. Your Laravel validator passed it as valid the whole time. The 72-Byte Rule bcrypt has a hard input limit of 72 bytes. Not characters - bytes. When you call password_hash($password, PASSWORD_BCRYPT) , PHP silently truncates anything past byte 72. Most developers know this in theory. But for ASCII-only apps, it never bites. 72 ASCII characters is already a very long password, and the silent clip is harmless in practice. The trouble starts with multi-byte scripts. How Many Characters Fit? Character set Bytes per char Effective bcrypt limit ASCII 1 72 chars Cyrillic 2 36 chars CJK (Chinese, Japanese, Korean, common block) 3 24 chars Emoji 4 18 chars Past the byte limit, a longer password adds no security at all. A 200-character Cyrillic password hashes identically to its own first 36 characters. Byte 73 and beyond simply do not exist from bcrypt's point of view. So "longer always produces a stronger bcrypt hash" is not true. A Cyrillic user with a 37-character password gets silently truncated at char 36. The hash is still consistent. The user logs in fine, but any variation past character 36 doesn't matter to bcrypt. Annoying from a security standpoint, but it does not break login. The Split-Byte Trap The 72-byte limit cuts at a byte boundary, not a character boundary. If a multi-byte character falls on that cut, bcrypt bakes in an incomplete UTF-8 sequence. // 35 Cyrillic chars = 70 bytes, emoji = 4 bytes, total = 74 bytes $password = str_repeat ( 'А' , 35 ) . '🔑' ; $hash = password_hash ( $password , PASSWORD_BCRYPT ); password_verify ( $password , $hash ); // ? password_verify ( str_repeat ( 'А' , 35 ), $hash ); // ? password_verify ( str_repeat ( 'А' , 36 ), $h

You update WordPress on a quiet afternoon — a routine release, the kind you've installed a hundred times. The dashboard says everything went fine. Then the 404s start: not a handful, but every long-headlined article in your archive, all at once, all in Arabic. Nothing in the update log mentions it. No plugin changed. And the cruel part: the data that made those URLs work is already gone — shaved off inside a database-upgrade routine that ran for a few milliseconds and reported success. This isn't a freak accident or a broken plugin. It's three separate assumptions baked into WordPress core, each hard-coding the same number — 200 — and Arabic sites are almost uniquely exposed to all three. We hit this running WordPress for Arabic newsrooms, the same high-traffic publishing we've written about surviving breaking-news spikes . We traced it to the exact lines in core and built a fix that survives every future update. Here's the whole story. Why Arabic URLs hit a wall English never does WordPress stores a post's slug in the post_name column of wp_posts , and a category or tag slug in the slug column of wp_terms . Both are VARCHAR(200) by default — room for 200 characters, which for an English headline is generous. "Everything you need to know about our new pricing" is barely fifty. You'd have to write a paragraph to run out. Arabic is a different arithmetic, because of what WordPress actually stores in that column. It doesn't keep the raw Arabic text — it stores the percent-encoded form, the same %XX sequence that travels in the URL. Take a single word: الذكاء → %d8%a7%d9%84%d8%b0%d9%83%d8%a7%d8%a1 Every Arabic letter is two bytes in UTF-8, and every byte becomes a three-character %XX token. So one Arabic character costs about six characters of column space. Do the division: VARCHAR(200) holds roughly 33 Arabic characters. A normal news headline — "القبض على المتهمين في قضية الاحتيال الإلكتروني" — blows past that before it's halfway done. So Arabic publishers learn early

I need your help. I've problems with an Navigation button on ios. On Windows in all browsers it's working good but on an ios device the menu isnt opening. I've tried to run devtools on an ios device to take a look in the console but this stays empty. https://rb.gy/7o5yql This is the url of the website. I've tried to remove the country flag and the logo i thought it was in the way of the button but nothing helps. Who would like to take a look at it?

(Without Fighting upload_max_filesize ) You deploy your app. A user picks a 400 MB video. They hit upload. The progress bar freezes. Then — nothing. You check the logs. POST Content-Length exceeded post_max_size . Again. We've all been there. The fix is usually "raise PHP limits" or "use S3." Both work — until you're on shared hosting, a legacy VPS, or a client who won't touch php.ini . That's the problem Pinion solves. What is Pinion? Pinion is an open-source resumable chunked upload protocol for PHP. Instead of one giant multipart/form-data request, the browser sends the file in small parts (default: 5 MB). The server stores each part, then assembles the final file on disk. Three steps. That's the whole contract: init → upload parts → complete Package Registry Role pinoox/pinion Packagist PHP server engine @pinooxhq/pinion-client npm Browser client Protocol id: pinion · version: 2 Why not just use S3? Object storage is great. But sometimes you need files on your server : A CMS media library on local disk A Laravel app without cloud budget Shared hosting with no S3 SDK An admin panel behind a simple PHP API Pinion isn't a CDN or a storage service. It's a protocol — a stable HTTP contract that works in plain PHP, Laravel, or Pinoox. How it works (30-second version) sequenceDiagram participant Browser participant API participant Disk Browser->>API: POST /init (filename, size, fingerprint) API-->>Browser: upload_id, chunk_size, missing_indexes loop Each part Browser->>API: POST /upload (chunk + SHA-256 hash) API->>Disk: store part end Browser->>API: POST /complete API->>Disk: assemble file API-->>Browser: done ✓ Resume is built in. The client sends a fingerprint ( name:size:lastModified:type ). If the connection drops, the same file picks up where it left off — only missing parts are re-uploaded. Integrity too. Each part gets a SHA-256 chunk_hash . The server can reject corrupted chunks before they pollute your disk. Server side: 10 lines of PHP composer require pinoo

If you're shipping a commercial WordPress plugin, sooner or later you'll need a licensing system. Something that lets paying customers activate the plugin on their site, locks it to that domain, and stops people from sharing the same key across fifty sites. The default answer in the WordPress world is Freemius or EDD Software Licensing. They're great. They're also a revenue share, a third-party dependency, and a black box you don't control. When we built RideCab WP , a commercial WooCommerce taxi booking plugin, we decided to build our own. Here's the architecture, the code, and the gotchas we hit along the way. What a Licensing System Actually Needs to Do Before writing any code, get clear on the requirements. A real plugin licensing system needs to: Generate unique license keys when someone buys Let the customer activate the key on their site Bind that key to one (or N) domains Validate the key periodically so revoked or expired keys stop working Handle deactivation when a customer moves to a new domain Fail gracefully — never lock a paying customer out because your license server hiccuped Optionally: deliver plugin updates only to valid license holders We'll cover 1 through 6 in this post. Update delivery is a separate beast and I'll write it up next. The Architecture The system has two halves that live in two different places. The license server runs on your own infrastructure — for us, it's a WordPress must-use plugin (mu-plugin) on the same WordPress install that powers our marketing site. It: Stores license keys in a custom database table Exposes a small REST API for activate, deactivate, and validate calls Provides an admin dashboard to view, create, and revoke keys The client is a PHP class shipped inside the commercial plugin (RideCab WP, in our case). It: Adds a license settings page to the plugin Calls home on activation Caches the validation result Re-validates quietly in the background Two pieces, talking over HTTPS, with the customer's domain as the b

I have just finished writing API Artisan: A Guide to Building APIs with Laravel , and I am giving it away for free. Before you commit to 300-odd pages, let me give you the short version: the tips, patterns, and small decisions that separate an API that technically works from one that developers are genuinely happy to depend on. None of this needs more hardware, a different framework, or a bigger team. It needs you to point your attention at the right things. These are the ones I keep coming back to. Start by measuring the right thing Ask most teams how they know their API is good and you get a single question back: does it work? Can I hit this endpoint and get a response? That question is necessary, and it is nowhere near enough. The question I want you to ask instead is whether your API is liveable with. Can a developer read your docs, understand your auth model, make a successful request, and handle an error without contacting support, trawling a forum, or guessing what a status code is trying to tell them? The gap between "works" and "liveable with" never shows up in a sprint retro, but it shows up everywhere else: in support volume, in integration timelines that overrun, and in the quiet moment a developer decides to build around your API rather than with it. Everything else in the book hangs off one mindset shift: an API is a product. It has users. Treat it as an implementation detail and it will behave like one. It will change without warning when your internals change, and it will be inconsistent because different people wrote different parts on different days with different conventions. Write the contract before the code The natural way to build an endpoint is to write the handler, return some data, and document it afterwards if there is time. It feels efficient, and in the short term it is. The problem is what it produces: a contract that was never designed, only discovered. Let me show you the trap, because I have watched it catch good developers. You have

Do you really need a full framework to handle a few API endpoints or webhooks? Laravel and Symfony are excellent tools — for large applications. But when you're building a focused microservice, a webhook receiver, or a lightweight REST API, bootstrapping a full-stack framework means carrying hundreds of files, a massive autoloader, and a dependency tree you'll never fully use. That's the problem webrium/core was built to solve: a minimalist, zero-dependency PHP micro-framework written entirely from scratch, designed to stay out of your way. Installation composer require webrium/core That's it. No configuration files to publish, no service providers to register. The Entry Point Every webrium application starts with the same three lines: <?php require_once __DIR__ . '/vendor/autoload.php' ; use Webrium\App ; use Webrium\Route ; App :: initialize ( __DIR__ ); // ... your routes here App :: run (); App::initialize() sets the root path and loads the global helper functions. App::run() initializes error handling and dispatches the current request through the router. Routing The router supports all standard HTTP methods. Route handlers can be closures, a Controller@method string, or an [Controller::class, 'method'] array. Basic routes: Route :: get ( '/status' , fn () => [ 'status' => 'alive' ]); Route :: post ( '/items' , fn () => [ 'created' => true ]); Route :: put ( '/items/{id}' , fn ( $id ) => [ 'updated' => $id ]); Route :: patch ( '/items/{id}' , fn ( $id ) => [ 'patched' => $id ]); Route :: delete ( '/items/{id}' , fn ( $id ) => [ 'deleted' => $id ]); Route handlers return an array — the framework automatically encodes it as JSON and sends the correct Content-Type header. Dynamic parameters: Route :: get ( '/users/{id}/posts/{postId}' , function ( $id , $postId ) { return [ 'user_id' => $id , 'post_id' => $postId , ]; }); Named routes: Route :: get ( '/users/{id}' , fn ( $id ) => [ 'id' => $id ]) -> name ( 'users.show' ); // Generate the URL elsewhere: $url = rout

Ever wanted to turn a simple PHP host into a gateway for your local network? I built host2gateway to do exactly that. ProfiDE / host2gateway Uses a PHP host or web server to create a gateway that securely allows access to clients through it. host2gateway host2gateway is a tool designed to provide access from a web server (Gateway) to a client without requiring static IP addresses, port forwarding, changing firewall rules, or other complex configurations . It is written in PHP and can be deployed on most hosting provider environments. Features No need for static IP or port forwarding: There is no requirement to modify your firewall or router settings. Platform-independent: Works anywhere PHP 8.2 or higher is supported, making it suitable for most shared hosting services. Lightweight and simple: Minimal dependencies and easy deployment. Strong encryption built-in: Uses a powerful encryption mechanism that secures all communication, even if SSL/TLS is not available on the hosting provider. Your data is protected at all times, regardless of your environment. How It Works The client establishes an outbound connection to a Gateway server that is accessible from the internet (a PHP-enabled web host). Both sides communicate… View on GitHub 🔥 What is host2gateway? It's a lightweight tool that transforms any server running PHP into a gateway that can route traffic, manage requests, and act as a bridge between your local network and external services. No heavy dependencies. No complex configs. Just PHP, Cron and a network interface. 🧠 Why I built this Most gateway solutions are bulky, written in Go or Rust, and require root access and system-level changes. But what if you only have: A shared hosting account A basic VPS with PHP enabled A Raspberry Pi running a PHP server host2gateway fills that gap. It gives you gateway-like capabilities using the tools you already have. 🛡️ Use cases Use Case Description Local network bridge Connect isolated parts of your network Traffic inspe

TL;DR: Pest PHP can test the structure of your code, not just its behavior. Write your team rules as architecture tests and CI enforces them on every commit. One such test caught a multi-tenant data leak that a human review had missed. We had a rule. Every model holding tenant-specific data must use our BelongsToTenant trait. That trait adds the global scope that keeps one clinic from seeing another clinic's data. The rule was in onboarding. It was in the code review checklist. Everyone knew it. A developer joined the team. Three weeks in they added a new model and forgot the trait. The reviewer was focused on the business logic, which was genuinely well written, and did not notice the missing trait. The model shipped. For two days one clinic could see fragments of another clinic's data in one specific report. A support ticket caught it. Our tests did not. That was the day architecture tests went into the project. What an Architecture Test Is Most tests check behavior. Given this input the function returns that output. An architecture test checks structure instead. It asserts things about how the code is organized rather than what it computes. Pest has an arch function for exactly this. // tests/Architecture/ArchTest.php arch ( 'tenant models must use the BelongsToTenant trait' ) -> expect ( 'App\Models' ) -> toUseTrait ( 'App\Traits\BelongsToTenant' ) -> ignoring ( 'App\Models\SystemSetting' ); arch ( 'controllers may not touch the DB facade directly' ) -> expect ( 'App\Http\Controllers' ) -> not -> toUse ( 'Illuminate\Support\Facades\DB' ); arch ( 'services may not depend on the HTTP request' ) -> expect ( 'App\Services' ) -> not -> toUse ( 'Illuminate\Http\Request' ); arch ( 'no env calls outside config files' ) -> expect ( 'App' ) -> not -> toUse ( 'env' ); These run in CI on every commit. Break a rule and the build fails with a message naming the rule and the file that broke it. The Tests That Earned Their Keep The tenant trait test caught four more models over

Book: Decoupled PHP — Clean and Hexagonal Architecture for Applications That Outlive the Framework Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools Me: xgabriel.com | GitHub You ship a list endpoint. GET /orders . It returns the customer's orders, newest first. Clean. Then product wants a status filter. Then a date range. Then "only orders over 100 euros". Then pagination. Then sort by total, descending. Six months later the controller signature reads like a tax form, and the repository method that backs it is findByCustomerAndStatusAndMinTotalBetweenDatesOrderedBy(...) with nine parameters, three of them nullable. So you "fix" it. You let the caller pass a Doctrine QueryBuilder into the repository. Or worse: the use case starts assembling WHERE clauses as strings because that was the fastest way to add the next filter on a Friday. Now your application layer knows about table aliases and SQL operators. The domain speaks SQL, and the whole point of having a repository interface is gone. There is a shape that holds: a query object the domain builds, and an adapter that translates it into SQL. The caller describes what it wants in domain terms. The adapter decides how to fetch it. The leak, concretely Here is the version that grows out of control. Every new filter is another nullable parameter. public function search ( ?string $customerId , ?string $status , ?DateTimeImmutable $from , ?DateTimeImmutable $to , ?int $minTotalCents , string $sortBy = 'placedAt' , string $direction = 'DESC' , int $page = 1 , int $perPage = 20 , ): array ; Nine parameters, half of them nullable, two of them ( sortBy , direction ) carrying raw column names that map straight to SQL. Add a filter and the signature grows again. Every caller has to remember positional order. And $sortBy is a column name leaking through the port: t

Book: Decoupled PHP — Clean and Hexagonal Architecture for Applications That Outlive the Framework Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools Me: xgabriel.com | GitHub You open a use case that places an order. Near the top of the constructor, alongside the repositories and the payment gateway, sits a Psr\Log\LoggerInterface . The method body calls $this->logger->info(...) three times. It looks harmless. It is the most common way framework concerns leak back into a domain you spent weeks keeping clean. PSR-3 is a fine standard. Monolog is the default implementation in most PHP projects, and it earns that spot. The problem is not the library. The problem is where you point it. When LoggerInterface is a constructor argument in your application layer, your use case now depends on a package whose surface area you do not control, whose log levels you may not want, and whose context conventions are someone else's. The dependency arrow points the wrong way. What PSR-3 drags in Psr\Log\LoggerInterface is eight level methods plus a generic log() . The level taxonomy comes from RFC 5424 syslog: emergency , alert , critical , error , warning , notice , info , debug . That is a system-administration vocabulary. Your domain does not speak it. When a use case calls $this->logger->warning('payment retry') , you have to ask: is a retry a warning or a notice ? The answer is an infrastructure judgment call wearing a domain costume. The method signature also accepts an arbitrary array $context and a string|Stringable $message with {placeholder} interpolation. None of that is something your application code should be deciding. <?php declare ( strict_types = 1 ); namespace App\Application\Order ; use Psr\Log\LoggerInterface ; final readonly class PlaceOrder { public function __construct ( private OrderRepository $ord

Book: Decoupled PHP — Clean and Hexagonal Architecture for Applications That Outlive the Framework Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools Me: xgabriel.com | GitHub You open a use case that places an order. It loads a customer, builds the order, charges a payment gateway, saves, publishes an event. Clean. Then a sprint ago someone added a retry loop around the charge call, because the gateway flaps under load. Now the use case has a for ($i = 0; $i < 3; $i++) , a usleep() , and a comment that says // gateway is flaky on Mondays . The business rule is buried under retry plumbing. A reader who wants to know what placing an order means has to skip past sleep timers and exception counters to find it. Worse, the next person who adds a second outbound call copies the loop. Soon every call to the network has its own hand-rolled retry, each with a slightly different backoff, none of them tested. The use case learned about transient failure. It should never have. Transient failure is not a business rule A use case answers one question: what does the application do when this thing happens? Place an order. Cancel a subscription. Issue a refund. Those are decisions the business cares about. "The payment gateway returned a 503 and we should try again in 200ms" is not a business decision. It is a property of the network between your process and theirs. The domain does not know the gateway is HTTP. It does not know there is a network at all. It asked a port to charge a customer, and the port either succeeds or raises a domain exception. Here is the port, stated in domain language: <?php declare ( strict_types = 1 ); namespace App\Application\Port ; use App\Domain\Customer\CustomerId ; use App\Domain\Shared\Money ; interface PaymentGateway { public function charge ( CustomerId $customerId , Money $amount , s

Book: Decoupled PHP — Clean and Hexagonal Architecture for Applications That Outlive the Framework Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools Me: xgabriel.com | GitHub You have an Order . It owns line items and a shipping address. In the database that is three tables: orders , order_items , order_addresses . The aggregate is one thing in the domain and three rows-with-children in storage. Now look at what most codebases do with that. The service loads the order, loops the items, saves each one in its own statement. Halfway through, a unique-constraint violation throws. The order header is already committed. Two items are in. One address is missing. You have a row in orders that no part of the system considers valid, and no single place to point at when you ask how it got there. The aggregate is supposed to be a consistency boundary. Saving its parts in separate, independently-committing operations breaks that boundary on the way to disk. This post is about closing it: one repository, one transactional save across every table, and a read path that rebuilds the whole object from rows without leaking the ORM into the domain. The aggregate the domain sees The domain class has no idea it lives in three tables. It holds its children directly and guards their invariants. <?php declare ( strict_types = 1 ); namespace App\Domain\Order ; use App\Domain\Shared\Money ; final class Order { /** @var list<LineItem> */ private array $items ; private function __construct ( private readonly OrderId $id , private readonly CustomerId $customerId , array $items , private Address $shipTo , private OrderStatus $status , ) { if ( $items === []) { throw new InvalidOrder ( 'order needs an item' ); } $this -> items = array_values ( $items ); } public static function place ( OrderId $id , CustomerId $customerId , array $it

Book: Decoupled PHP — Clean and Hexagonal Architecture for Applications That Outlive the Framework Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools Me: xgabriel.com | GitHub Open a PHP REPL and type 0.1 + 0.2 . You get 0.30000000000000004 . Now imagine that drift sitting in a total column on an invoice. The bug report does not say "IEEE 754 rounding." It says "the customer was charged one cent too much and finance wants to know why." Money is not a number. It is an amount paired with a currency, and it follows rules a float does not know about. You cannot add 10 USD to 10 EUR. You cannot store 19.99 in a binary fraction and expect it back. You cannot round a third of a cent without deciding how to round it, and that decision belongs to your business, not to your storage engine. This post builds a small Money value object that gets the currency safety right, then shows when to stop hand-rolling and wrap brick/money behind a domain port instead. The point of the port is the same point as every port: the rounding rules live in your domain, and the library stays swappable. Why a float is the wrong type Three separate problems hide inside float $amount . The first is representation. A float is a binary fraction. Decimal amounts like 0.10 have no exact binary form, so they round on every store and load. Sum a few thousand line items and the error compounds into real cents. The second is the missing currency. A bare number cannot tell you whether 1000 means ten dollars or one thousand yen. Two amounts in different currencies are not comparable, but the type system lets you add them anyway. The third is the rounding rule. When you split 10.00 across three line items, you get 3.333... per item. Someone has to decide who absorbs the leftover cent. A float makes that decision silently and inconsistently. The fix

Book: Decoupled PHP — Clean and Hexagonal Architecture for Applications That Outlive the Framework Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools Me: xgabriel.com | GitHub You add a column to a table. discount_cents , nullable, default zero. A small migration, a five-minute ticket. The next morning a teammate pings you: orders placed overnight have a discount of null where the domain expected zero, and the total calculation now throws a TypeError deep inside a value object. You trace it back. A reflection-based mapper copied the new column straight onto a property the domain class did not declare, then the next read pulled it back as null and handed it to Money . Nobody wrote the line that connected discount_cents to the domain. The mapper guessed, and the guess leaked the table's shape into a class that was supposed to know nothing about tables. This is the case against automatic mapping at the persistence boundary. A hand-rolled mapper is more typing. It is also the seam that stops the database schema from reaching into your domain. What the boundary is for In a hexagonal layout the domain Order knows about line items, currencies, and the rule that an order needs at least one item. It does not know there is a orders table with a discount_cents column. The repository adapter is the only place those two worlds touch, and the mapper is the translator that stands at that seam. A reflection or annotation-driven mapper collapses the seam. It reads the persistence shape, walks the domain object's properties, and copies whatever names line up. When the two shapes match, it feels free. When they drift, the drift travels silently across the boundary you built it to protect: a renamed column, a new field, a type that does not round-trip. The whole point of the adapter is that the domain and the table can cha

How a PHP SDK Can Save You Hundreds of Lines of API Integration Code Most APIs provide documentation, examples, and maybe even a Postman collection. That's usually enough to get started. But once your application grows, you'll quickly discover that working directly with HTTP requests introduces a surprising amount of repetitive code. You end up writing the same things over and over: Authentication headers Request serialization Response parsing Error handling Pagination logic DTO mapping This is exactly why SDKs exist. In this article, we'll look at how a PHP SDK can simplify API integrations and reduce maintenance costs over time. The Hidden Cost of Direct API Calls Let's imagine you're integrating a URL shortening API. A typical implementation might look like this: $client = new GuzzleHttp\Client (); $response = $client -> post ( 'https://example.com/api/links' , [ 'headers' => [ 'X-Api-Key' => $apiKey , 'Content-Type' => 'application/json' , ], 'json' => [ 'url' => 'https://example.com' ] ] ); $data = json_decode ( $response -> getBody () -> getContents (), true ); This doesn't seem bad. Now repeat it for: Create link Update link Delete link Get link List links Create group Update group Get profile Eventually your codebase becomes filled with API boilerplate. The business logic becomes harder to see because it's buried under HTTP implementation details. What a Good SDK Does A well-designed SDK abstracts repetitive tasks and exposes a clean programming interface. Instead of dealing with HTTP requests directly, developers work with resources and objects. For example: $link = $client -> links () -> create ([ 'url' => 'https://example.com' ]); This is easier to read and easier to maintain. The SDK becomes responsible for: Authentication Request building Validation Serialization Response mapping Exception handling Consistent Error Handling One common problem with raw API integrations is inconsistent error handling. Without an SDK, every request may need its own validat

WordPress maintenance automation has a long-running market, especially outside Japan. ManageWP, MainWP, WP Umbrella, InfiniteWP — each has more than a decade of history behind it. While building our comparison pages, we surveyed all four side by side. An interesting pattern emerged: three things none of the four tools offer . Each is a gap the industry has long treated as "not feasible," and there are structural reasons why. Here's a look at those three unsolved areas — and why they remain unsolved. Gap 1 — Per-plugin updates with HTTP checks between each one In most maintenance tools, plugin updates run in bulk . After the batch, the tool takes a sitewide screenshot diff or HTTP status check, and if anything is broken, "Safe Updates" or "Atomic Updates" features roll everything back at once . Why isn't "one at a time with an HTTP check between each" the standard? The main reason is API design constraints . WordPress's built-in wp_ajax_update-plugin and Worker-plugin APIs (like ManageWP Worker) are designed around batch processing. Doing an HTTP probe from an external host after every single update would add significant per-update overhead. The industry has settled on "bulk update → bulk check" as the natural granularity. The side effect: identifying which plugin caused the breakage often falls to the operator's manual investigation. Gap 2 — Pinpoint rollback (only the one that broke) The industry-standard "Safe Updates" feature is fundamentally a "roll back everything" design. If 20 plugins are batched together and one breaks the site, all 20 updates revert. It's a safety-first choice — but operationally, it means the 19 that finished cleanly are also lost. Why isn't pinpoint rollback (revert only the one that broke) the standard? The root cause is state-management complexity . To pinpoint rollback, you need to keep the pre-update files of each plugin individually. Storage, transfer cost, and dependency consistency checks become impractical over a Worker-plugin HTT