Blog

Webhook Basics: How They Differ from Polling and What the Receiver Must Plan For “Notify me when an order comes in.” “Update the status once the payment completes.” Whenever you integrate with an external service, you face the same question: how do you learn that something happened on their side? There are two broad answers. Ask repeatedly (polling), or be told (webhooks). This article compares them with a small calculation and lays out what the receiving side should think about at design time. Note: The numbers are a back-of-the-envelope calculation and a minimal experiment with Python’s standard library, not measurements of any particular service. On sender verification, this article sticks …

What Is Idempotency? Designing Operations That Are Safe to Run Twice “The job stopped halfway, so I ran it again.” Whether that is safe depends on one property: whether the operation is idempotent. An operation is idempotent if running it many times leaves the system in the same state as running it once. Network failures, timeouts, double clicks, and overlapping schedules all mean the same operation will eventually run twice. This article contrasts idempotent and non-idempotent operations using a tiny experiment, then walks through the common designs that make operations safe to repeat. Note: The experiment used an in-memory SQLite database from Python’s standard library. It is a minimal example …

“Your Core Web Vitals are poor” is hard to act on. Three metric names, three different units, three different thresholds. This article explains which moment of a page’s life each metric (LCP, INP, CLS) measures. We also point curl at a real page on this blog and read what the HTML alone can tell us: which files it loads, whether images declare their dimensions, and so on. Note: The thresholds below are the ones published on Google’s web.dev. The measurements here are limited to what we could read from the HTML and response headers from one machine. We did not measure what real visitors experience (field data), so this is …

While a plugin or core update runs, visiting the site can show a short “Briefly unavailable for scheduled maintenance” message. Normally it disappears on its own. But if an update is interrupted (a closed browser tab, a dropped connection), it is natural to wonder whether the site will be stuck on that screen forever. The mechanism behind it is a single small file in the site root: .maintenance. This article reads the WordPress 7.1.2 core source to show when the file is created, how it is judged, and when it stops mattering, then covers wp maintenance-mode and a sensible order of checks when an update seems to have stalled. Note: …

Sooner or later every site changes a URL: a cleaner slug, a move to HTTPS, a new domain or subdomain. Each time, the same question comes up: should the redirect be a 301 or a 302? I covered HTTP status codes in general in “HTTP Status Code Basics.” This article narrows in on 301 and 302: how search engines interpret each one, and which redirects WordPress already sends on its own. The examples come from running curl against this blog. A redirect is “don’t look here, look there” A redirect response has two parts: a status code that describes the nature of the move, and a Location header that says …

Most hosting control panels have a “PHP version” switch, and WordPress Site Health keeps recommending a newer one. Yet switching is still a common cause of white screens and the “There has been a critical error on this website” message. The key to understanding what breaks, and when, is the difference between two stages: deprecated and removed. For this article I ran the same few lines of code under several PHP versions (7.0 through 8.5) installed on the shared server that hosts this blog. Features disappear in stages When PHP decides to retire a function or syntax, it usually goes through three stages: Works normally — no messages. Deprecated — …

When you edit a post in WordPress and click “Update”, a “Revisions” item appears in the sidebar, letting you compare earlier versions and restore one. It is a useful safety net against accidental overwrites. At the same time, maintenance advice often warns that revisions pile up in the database and should be capped. Where exactly are revisions stored, and in what form? How do they differ from autosaves and auto-drafts? As promised at the end of the previous article on autoload options, this post answers those questions using read-only queries against this blog’s own WordPress database (7.1 series) and the core source code. Revisions live in the same table as …

Besides posts and pages, every WordPress database has a table called wp_options. It stores site-wide settings: the site title, the permalink structure, the list of active plugins, and the configuration of each plugin, one row per setting. That table has a column named autoload. It looks like a simple flag, but any row with autoload enabled is loaded on every single request, whether that request needs it or not. When a long-running site’s admin screens gradually get heavier, a bloated autoload set is one of the first things worth checking. Following the previous article on database index basics, this post uses measurements taken on this blog’s own WordPress database (7.1 …

Every time we publish a post on this blog, we run an SEO audit script that checks the title, meta description, canonical URL and hreflang tags. On the English posts, one number keeps showing up: 164 chars. The theme is written to cap meta descriptions at 160 characters, yet the audit keeps reporting more. Is the theme broken, or is the audit wrong? Neither. They are simply counting two different strings. This post uses that “phantom overflow” as a way into two questions: why meta descriptions have a length guideline at all, and how many different things “length” can mean. What a meta description is (and is not) A meta …