标签：#HP

GitHub热门项目 | A free open source IT asset/license management system | Stars: 14,282 | 6 stars today | 语言: PHP

A forgotten password, a security plugin that blocked your own IP by mistake, a plugin bug that turns the admin screen white — the causes vary, but the result is the same: you can’t log in to wp-admin. Note: WP-CLI is a command-line tool for managing WordPress, invoked as wp . It operates directly on the server, without going through a browser. This is exactly the situation where WP-CLI is useful. It works here because it never touches wp-login.php — it reads and writes the WordPress database and filesystem directly, so a broken login screen doesn’t affect it at all. Why WP-CLI keeps working when wp-admin doesn't A normal login follows the path: browser → wp-login.php → authentication → wp-admin. If anything along that path is broken — a plugin throwing a fatal error during authentication, a security plugin blocking your IP, a fatal error in the admin theme — the login itself can’t complete. WP-CLI connects over SSH and reads/writes the wp_users and wp_options tables (and the filesystem) directly. The code in wp-login.php is never executed, so problems on that path don’t matter. This does require that SSH access itself still works — on most hosting providers, SSH is a separate access path from the admin dashboard, so it usually still works even when wp-admin doesn’t. Scenario 1: Forgotten password # List administrator accounts wp user list --role = administrator --fields = ID,user_login,user_email # Overwrite the password directly wp user update 1 --user_pass = 'a-strong-new-password' wp user update writes the new password directly to the database row — no password-reset email, no token, no waiting on a delivery that might land in spam or not arrive at all. Scenario 2: A security plugin blocked your own IP Login-attempt-limiting plugins occasionally misclassify legitimate activity as an attack and add the working IP to a block list. # Deactivate the plugin responsible for the block wp plugin deactivate <plugin-causing-the-lockout> # Re-enable it later, after reviewin

After a domain migration or HTTPS switch, "all plugin settings are gone" or "Elementor layouts are broken" is a common outcome. The cause, in most cases, is running a string replacement against the WordPress database without accounting for PHP serialized data. WordPress stores plugin configurations, custom field values, and widget settings in PHP’s serialized format. Standard SQL replacements — phpMyAdmin’s find-and-replace, raw UPDATE statements, sed on a .sql dump — rewrite the string value without updating the length metadata that serialization embeds alongside it. The result is a database that appears intact but returns false on every read of the affected values. wp search-replace handles this correctly. Understanding why makes the pre- and post-execution steps more deliberate. What PHP serialization stores alongside the value A serialized entry in WordPress looks like this: a : 2 : { s : 4 : "home" ; s : 22 : "http://example.com/top" ; s : 5 : "title" ; s : 8 : "My Site" ;} The segment s:22:"http://example.com/top" means "a string of 22 bytes." The s:N: prefix records the byte length. When a simple string replacement changes http://example.com to https://example.com : Before: s:22:"http://example.com/top" (22 bytes) After: s:22:"https://example.com/top" (23 bytes) The s:22 stays unchanged even though the actual string is now 23 bytes. PHP’s unserialize() detects this mismatch and returns false . The plugin reads false instead of its configuration array and behaves as though the settings were never saved. phpMyAdmin’s find-and-replace executes a SQL UPDATE at the storage layer. No PHP context exists there — it can’t know the column contains serialized data, and it doesn’t adjust the length prefix. How wp search-replace handles it wp search-replace operates at the PHP layer, not the SQL layer: Reads each column value Checks whether it’s serialized using is_serialized() If serialized: calls unserialize() to expand it into a PHP array or object Applies the string r

Making classics more accessible I have a soft spot for mythology and classic stories. I have read most of the books on Abridged Shelf at least once, several of them more than that. But a lot of them are long . Epic poetry is not something you casually get through on a Tuesday evening, and the older translations can be genuinely hard going. The language demands focus, and focus is a resource I do not always have. So I made shorter versions. Abridged Shelf is a free library of public domain classics that I have abridged and modernized. Abridged, not summarized. The distinction matters a lot to me. I am not writing study notes or plot recaps. I take the actual text and condense it: the B-plots that do not carry the story, the scenes that spend forty lines describing a shield, those get compressed down into the beats that matter. What is left is still the story, told in its own voice, just tighter. The other half is the language. A lot of these translations are over a century old, and the English shows it. So I modernize spelling and phrasing into contemporary English. Again, not simplified. This is not a children's edition and I am not dumbing anything down. It is the same book, in language that does not fight you. I also made some editorial calls. For the Greek epics I use the Greek names rather than the Roman ones that a lot of older translations default to, because if we are reading Homer then it should be Athena and not Minerva. Small thing. Matters to me. And as a nod to a certain static site generator I maintain, the first book I abridged was the original Strange Case of Dr Jekyll and Mr Hyde . It is already short. Now it is very short. I did a few more by Stevenson after that, mostly because they were quick and I needed to get the workflow right before pointing it at an epic poem. The abridgment process I knew from the start that I needed to use AI for this. I also do not entirely trust AI, which is a useful combination of beliefs to hold at the same time. It me

I woke up to two emails that immediately caught my attention. One was from my website monitoring service (I use UptimeRobot, no affiliation) reporting that a client's website was down. The other was from my VPS provider informing me that they had suspended my VPS due to abuse. I logged into the control panel and immediately noticed a massive CPU spike. The server had gone from its usual 15–20% CPU usage to a sustained 100% for nearly four hours before the provider shut it down under their fair usage policy. My first clue was xmlrpc.php . It was consuming a significant amount of resources, so I started researching it. I'm not primarily a WordPress/PHP developer, and I was surprised to learn that XML-RPC exposes functionality for remote management of WordPress. I disabled XML-RPC, brought the VPS back online, and thought the problem was solved. It wasn't. The next day I woke up to the exact same two emails. This time my VPS provider had already imposed CPU limits on the server. I noticed a few kernel-looking processes consuming CPU, assumed they were related to the throttling, and restarted the VPS. A few hours later, it was offline again. At that point I knew I was dealing with a compromise rather than a performance issue. I began investigating the WordPress installation and immediately found obvious signs of infection. There were numerous malicious PHP files ( index.php , cache.php , etc.) buried inside recursively nested directories such as: image / image / image / image / cache . php The deeper I looked, the worse it became. The attackers had created: A rogue WordPress administrator account An unauthorized SSH key A root-level user on the VPS An administrator account inside CyberPanel This wasn't just a compromised website anymore. It was a full VPS compromise. My working theory was that the attackers exploited a vulnerable WordPress component (likely allowing arbitrary PHP upload or remote code execution), established persistence, and pivoted into the operating s

Hi everyone,I just released my first package — strides/laravel-api-module.The idea was simple: stop copying the same boilerplate code every time you create a new API resource. So I made a generator that creates a clean module structure using the Action + Repository + Transformer pattern.What you get with one command:Action classes Repository with interface Transformer (using spatie/laravel-data) Model and migration Routes file The package is well documented with examples.Would love to hear your feedback and suggestions!Links:Documentation: https://strides-hovo.github.io/Laravel-api-module/ GitHub: https://github.com/strides-hovo/Laravel-api-module Packagist: https://packagist.org/packages/strides/laravel-api-module

Guía crear Roles de Usuario usando RBAC Plano con PHP MySQL Agustin RamosJul 24, 2026PHP Stuffs El control de acceso basado en roles (RBAC) es utilizado en la mayoría de los sistemas para definir qué puede hacer cada usuario. En su versión más simple, conocida como RBAC plano, no es necesaria una tabla de permisos: cada usuario tiene un único rol, representado por un número, y ese número es el que determina qué se le permite hacer dentro del sistema. En esta guía es construido un módulo de RBAC plano completo, con base de datos, conexión, lógica de validación y ejemplos de uso, usando solo PHP y MySQL. Si necesitas repasar los fundamentos antes de continuar, puedes consultar nuestra guía de PHP y MySQL. Qué es el RBAC plano En este modelo, cada rol es representado por un ID numérico. La regla que se sigue en esta guía es simple: entre más bajo el número, mayor es el nivel de acceso. 1 = admin (mayor nivel de acceso) 2 = subadmin 3 = encargado 4 = empleado (menor nivel de acceso) Con esta lógica, validar “solo administradores o superiores” se reduce a una simple comparación: role_id <= 2. Base de datos Son necesarias únicamente dos tablas: rol y user. La columna role_id, dentro de user, es la que define el nivel de acceso de cada persona. Todo este bloque está guardado en el archivo schema.sql. Cómo ejecutarlo: copia todo el bloque de código y pégalo directamente en tu consola de MySQL (o en phpMyAdmin / MySQL Workbench). Esto crea la base de datos rbac_plano, sus tablas y los datos de ejemplo automáticamente. -- schema.sql CREATE DATABASE rbac_plano; USE rbac_plano; -- Tabla rol. -- El ID es usado como nivel: entre más bajo, más privilegios. CREATE TABLE rol ( id TINYINT UNSIGNED PRIMARY KEY, name VARCHAR(50) NOT NULL UNIQUE ); -- Se insertan los 4 roles base del sistema. INSERT INTO rol (id, name) VALUES (1, 'admin'), (2, 'subadmin'), (3, 'encargado'), (4, 'empleado'); -- Tabla user. -- Cada usuario tiene un único role_id (no hay tabla de permisos). CREATE TABLE us

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

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

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

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

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

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

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

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

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

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

Resellers threatened to ditch HP printing supplies for counterfeits.

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

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