DEV Community: Susumu Takahashi

The day a user told me "the running site looks weak" — rebuilding the three-state visual hierarchy with background color

Susumu Takahashi — Sat, 11 Jul 2026 04:48:47 +0000

After we'd shipped the colored borders for in-maintenance and completed sites on the multi-site list, real-world usage produced an unexpected report: "the running site somehow looks weak." Followed by: "the green border that's supposed to stick for 24 hours doesn't show up."

The first one was surprising. The running site has a pulsing blue border — it should be obvious. But when I looked at the screen again, yes, it did look weak relative to its neighbors. The problem turned out not to be the running-state color itself, but a hierarchy among the three states that had quietly inverted. This post walks through that visual-hierarchy collapse and rebuild, along with the "design oscillation" we'd accidentally introduced one round earlier.

At a glance, "running" looked weaker than "pending"

The multi-site list has three states:

Pending — sites queued up to be processed next
Running — the site currently being processed
Completed — sites finished within the last 24h

The old CSS painted them like this:

/* Old: no background for running, faint background for pending */
.site-running {
  border-color: #2563eb;
  /* no background-color */
  animation: pulse 2.2s ...;
}
.site-pending {
  border: 1px dashed #2563eb;
  background-color: rgba(37, 99, 235, 0.02);
}

"Running has a pulse, so it doesn't need a background. Pending gets a subtle fill." Sounds reasonable on paper. In actual use it produced the opposite effect.

Pending sites had a dashed border + a faint blue background — making their whole area speak. Running sites had no fill and asserted only through their border line. Filled areas are louder than lines, so the visual hierarchy was actually pending > running. "The running site looks weak" wasn't a perception bug. It was a design bug.

Express the hierarchy through background alpha

The fix consolidated everything onto a single principle: assign a background color to all three states, and use alpha values to encode the hierarchy.

.site-running {
  border-color: #2563eb;
  background-color: rgba(37, 99, 235, 0.08);  /* loudest */
  animation: pulse 2.2s ease-in-out infinite;
  box-shadow: 0 0 0 6px rgba(37, 99, 235, 0.0);  /* pulse a touch stronger */
}
.site-completed {
  border-color: #10b981;
  background-color: rgba(16, 185, 129, 0.05);  /* middle */
  box-shadow: inset 0 0 0 1px rgba(16, 185, 129, 0.25);
}
.site-pending {
  border: 1px dashed #2563eb;
  background-color: rgba(37, 99, 235, 0.02);    /* faintest */
}

The three alphas line up 0.08 > 0.05 > 0.02. That makes the running > completed > pending visual hierarchy numerically guaranteed. The regression test reads exactly that:

// test sketch
function test_running_alpha_is_higher_than_pending() {
  const r = getComputedAlpha('.site-running');
  const p = getComputedAlpha('.site-pending');
  assert(r > p, 'running should be louder than pending');
}

It's tempting to say "as long as the tones feel right, that's fine." But encoding the hierarchy in numeric alpha values pulls visual-design intent into a form a machine can verify. Someone swapping the values later? CI catches it.

The second report — "the 24h green border doesn't show up"

The same feedback included "the completion green border isn't appearing." I thought it was a separate bug, but it turned out to be a side effect from the previous round.

As written up in Detecting the running site from streaming logs, to fix the log-rewind false-detection bug, we'd abolished the "mark previous done on site switch" entirely and moved completion marking to a single batch at run-end. The false positives went away — but so did the green flash on the previous site during normal forward progression.

Normal forward run: when the system goes from site A to site B, the user expects "site A turns green right at that moment." With our previous fix, nothing turned green until the whole run finished. The blue pulse on the running site was the only visual signal in between.

Fix: "mark complete only on forward moves"

We wanted to keep the rewind defense but also bring back the mid-run green marking. The two looked mutually exclusive, but distinguishing forward moves via the execution-order index made both possible.

function _setRunningSiteId(siteId) {
  const newIdx = _runningSiteIdOrder.indexOf(siteId);
  const curIdx = _runningSiteIdIndex;
  const isForwardMove = newIdx === -1 || newIdx >= curIdx;

  if (isForwardMove && _runningSiteId && _runningSiteId !== siteId) {
    _markSiteCompleted(_runningSiteId);  // mark previous done only on forward moves
  }
  // Rewinds (newIdx < curIdx): do nothing (keep the previous-round defense)

  _runningSiteIdIndex = newIdx;
  _runningSiteId = siteId;
}

For site IDs not in the planned order (partial runs, unexpected sites), newIdx === -1 falls back to "treat as forward." The result:

Normal forward run (A → B): A turns green ✅
Log rewind (A reappears): ignored ✅

Both goals satisfied. "Rewind defense" and "restore forward-move state changes" had looked binary at first — adding one line for movement-direction detection is what reconciled them. Clean convergence for what had felt like an oscillating design.

Reflection — don't treat "design oscillation" as failure

Looking at the timeline:

V33 initial cut: mark previous done on every switch
V43's fix: kill switch-time marking to stop log-rewind false positives → batch-mark at run-end
This round: "the 24h green disappears" side-effect surfaced → restore forward-only marking to satisfy both

You could say "we should have nailed it from the start." But the other framing is that minimal fixes for real-world problems, then minimal fixes for the side effects of those fixes is a healthy progression. Designing the complete "rewind defense + forward-detection" combo upfront — before hearing actual usage feedback — is close to impossible.

Lessons — verify visual hierarchy with alpha values

Three principles to keep:

Filled area beats line in visual loudness. What looked like a confident pulsing border on the running state got out-shouted by a pending state with a quiet background fill. In a UI with three states, the most important state needs the strongest fill — not just the strongest border
Express visual hierarchy with numeric alphas — then test those numbers. Write 0.08 > 0.05 > 0.02 into the CSS, assert running > completed > pending in a test, and any future change that flips the values fails CI. Translate design intent into a form machines can guard
"Design oscillation" is a healthy progression, not failure. Side effects from a fix get fixed by the next round. Choices that initially look binary (rewind defense vs forward-move marking) often reconcile with one extra distinguishing axis. Chasing the perfect version upfront is less responsive to real usage than oscillating toward it

Reports of the form "X should stand out but doesn't" usually trace back to the relationship between X and its neighbors, not to X's color itself. When you're building a UI that puts three states side by side, deciding upfront — and encoding numerically — which one should be loudest saves the rebuilding later.

Visualizing maintenance status on the site list — blue pulsing border for running, green solid for done

Susumu Takahashi — Fri, 10 Jul 2026 00:35:23 +0000

When you're running maintenance across several WordPress sites in sequence, a list view with text-only status doesn't make "which site is being processed now" or "which ones are already done" easy to spot at a glance. A client put it plainly: "Make it visually obvious in the list which sites are in maintenance and which are finished."

A colored border is the obvious move, but there are real choices to make. What colors? Where do we get the state from? When does the "done" mark go away? And — can we ship this without touching the backend? This post walks through those four calls and the minimal frontend-only implementation we landed on.

Color picking — "red flashing" was the first thing we ruled out

How do you make the running site stand out? The intuitive answer is "blinking red," but that got cut early. Multi-site maintenance runs are long. Having something blink red somewhere on screen the whole time is a fatigue source.

We went with "a gentle blue pulse + a solid green border" instead:

Running: blue #2563eb border + a soft pulsing box-shadow (2.2s ease-in-out)
Done (within 24h): green #10b981 solid border + a faint inset shadow

@keyframes site-running-pulse {
  0%, 100% { box-shadow: 0 0 0 0 rgba(37, 99, 235, 0.4); }
  50%      { box-shadow: 0 0 0 6px rgba(37, 99, 235, 0); }
}
.site-running {
  border-color: #2563eb !important;
  animation: site-running-pulse 2.2s ease-in-out infinite;
}
@media (prefers-reduced-motion: reduce) {
  .site-running { animation: none; }   /* respect OS-level reduced motion */
}
.site-completed {
  border-color: #10b981 !important;
  box-shadow: inset 0 0 0 1px rgba(16, 185, 129, 0.25);
}

The prefers-reduced-motion: reduce rule stops the pulse for users who have reduced-motion enabled at the OS level (often people with vestibular sensitivity). If you're adding motion to grab attention, this is essentially required.

Zero backend changes — reuse the existing log stream

To tell the list UI "this site is being processed now," you need state from the server. The straightforward path would be a new /api/maintenance/status endpoint — but the maintenance logs were already being streamed to the frontend. The familiar [Site name] message format lines.

I realized that parsing those lines on the frontend would give us "the currently processing site" without touching the backend. No new endpoint.

function _detectRunningSiteFromLog(logText) {
  // Logs look like "2026-05-28 09:40:13 - [INFO] - [Site name] message"
  const lines = logText.split('\n');
  for (let i = lines.length - 1; i >= 0; i--) {  // scan from the tail
    const matches = [...lines[i].matchAll(/\[([^\]]+)\]/g)];
    for (const m of matches) {
      const candidate = m[1];
      // exclude log-level brackets
      if (['INFO', 'WARNING', 'ERROR', 'DEBUG', 'TRACE'].includes(candidate)) continue;
      // match against allSites by site_name
      const site = allSites.find(s => s.site_name === candidate);
      if (site) return site._id;
    }
  }
  return null;
}

Scanning from the tail picks up the most recent site name. [INFO]-style log-level brackets also match [...], so we exclude them explicitly. To handle lines that contain both [INFO] and [Site name], we walk all brackets in order.

On site switch, mark the previous one done

If _runningSiteId changes, marking the previous site as done gives you the natural "running → done" flow in the UI.

function _setRunningSiteId(siteId) {
  if (_runningSiteId && _runningSiteId !== siteId) {
    _markSiteCompleted(_runningSiteId);  // previous site = done
  }
  _runningSiteId = siteId;
  filterSites();                          // re-render the list to swap border colors
}

At this point in time, this implementation is "naive." What I didn't see coming was the non-monotonic order in which logs actually arrive — multiple site names interleaving back and forth, init loops that emit every site's name up front. Those gotchas eventually pushed us into three rounds of fixes, which I wrote up separately in Detecting the running site from streaming logs — why log-order inference broke. The short version: the "switch implies previous done" rule is fragile against log ordering, and we ended up rewriting it as a marker approach (detect only one specific line type).

The thing I missed in the naive first cut was that I'd implicitly assumed logs always advance monotonically. When you bolt visualization onto an async data source (like streaming logs), you need to think about the source's quirks from the start.

Auto-expire the done mark after 24h

If green stays forever, users lose track of "when was this site last maintained?" (especially over multi-day operations). But "vanishes on page reload" feels too flimsy.

The compromise: auto-expire after 24 hours. We save completion timestamps in localStorage and filter out entries older than 24h on load.

function _loadCompletedSites() {
  try {
    const raw = localStorage.getItem(KEY_COMPLETED_SITES);
    if (!raw) return {};
    const parsed = JSON.parse(raw);
    if (typeof parsed !== 'object' || parsed === null || Array.isArray(parsed)) {
      return {};                                       // reject bad types
    }
    const cutoff = Date.now() - 24 * 60 * 60 * 1000;
    const filtered = {};
    for (const [siteId, ts] of Object.entries(parsed)) {
      if (typeof ts === 'number' && ts > cutoff) {     // keep only within 24h
        filtered[siteId] = ts;
      }
    }
    return filtered;
  } catch (e) {
    return {};                                         // bad JSON, no localStorage, etc.
  }
}

Three layers of data defense: JSON parse failure, type mismatch, and "too old" all fall back to an empty dict. The whole thing is wrapped in try/catch so private-browsing or disabled-localStorage doesn't crash startup. "Nice-to-have" caches should never block boot if they're broken.

This 24h expiration ended up being the start of a longer story. We later reworked the lifetime design through several rounds — extending the TTL to 30 days, switching from "wipe all on maintenance" to "wipe only the executed sites," and so on. That whole arc is in Three pitfalls in a dashboard cache lifetime. The 24h here was "a reasonable-looking initial value" — once we got to real use, both "I'd like it to stay longer" and "please don't wipe everything when I maintain one site" came in from different angles.

Closing — "build the minimum, let production shake it"

Three principles from this round:

Before adding a new API, check whether an existing stream can be reused. The log streaming was already live, and parsing it on the frontend was smaller-blast-radius and faster to ship than a new endpoint. Zero backend changes, full state visualization
Accessibility is an automatic prerequisite when adding animation. prefers-reduced-motion: reduce support is mandatory if you're using motion to draw attention. The same reasoning ruled out "blinking red" upfront
Build "the naive first cut" expecting it'll be shaken in production. "On site switch, mark previous done" carried an implicit assumption about log ordering that turned out to be fragile. It got rewritten later as a marker approach. Shipping minimal and letting real use surface the failure modes ends up revealing the actual problems faster than upfront over-engineering

Visualization is often dismissed as "nice to have," but in practice it quietly reduces operator fatigue. The combination of multiple sites × long maintenance windows × near-zero visual signals was, frankly, just a fatigue source on its own. One color can pull more weight than you'd expect.

Three pitfalls in a dashboard cache lifetime — boot-time restore, TTL, and partial invalidation

Susumu Takahashi — Thu, 09 Jul 2026 01:43:04 +0000

We added a cache-first design to the cross-site updates dashboard, then wired the site-list badge to read from the same cache. Both ships went well.

But as soon as it hit real usage, we hit three distinct pitfalls around the cache's "lifetime" in quick succession: "the badges all disappear on refresh," "the 7-day TTL is too short," "running maintenance on one site clears all the badges." Each is a small spec call in isolation, but from the user's side, all three feel like the same symptom: "badges aren't sticking around the way I expect." This post walks through each fix and what we got wrong.

Pitfall 1 — All badges disappear on refresh

The first report was blunt: "Is it intentional that the pending-plugin badges all vanish when I refresh?"

Not intentional. It was a bug. _updatesDashState was designed as a localStorage-backed persistent cache — but the restoration call only ran the moment the dashboard was opened.

// Old: restored only when the dashboard opens
function openUpdatesDashboard() {
  _loadUpdatesDashStateFromLocalStorage();   // ← the only place this got called
  // ... render ...
}

Through this path:

App boot: in-memory _updatesDashState sits at its initial empty value
Site-list render: _getPendingPluginCountForSite sees the empty array, returns null
Result: every badge hidden

Restoration only happened when the user explicitly opened the dashboard. In the original designer's head, "the cache belongs to the dashboard" — but a later consumer (the site-list badge) rendered before the dashboard ever opened, and that path wasn't accounted for.

The fix was one line, in DOMContentLoaded:

document.addEventListener('DOMContentLoaded', () => {
  _completedSiteTimestamps = _loadCompletedSites();
  try {
    _loadUpdatesDashStateFromLocalStorage();  // ← restore at boot, always
  } catch (e) {
    // Don't block startup if localStorage is unavailable
  }
  // ... rest of init
});

The try/catch is there because some browser environments (private mode, etc.) disallow localStorage. Restoration is "nice to have" — if it fails, don't take down the app.

Lesson 1 — Tie cache restoration to the app's lifecycle, not its consumer

Putting restoration at "the first screen that uses the cache" was the mistake. If another screen might consume the same cache earlier, restoration belongs at app boot, once. Adding more readers later doesn't require touching the restoration logic.

Pitfall 2 — A 7-day TTL was too short

The next report: "Does the pending-plugin display in the list disappear after 7 days?"

The 7-day figure was a feel-based guess at implementation time. We'd assumed a workflow of "open the dashboard regularly." But real usage looks more like "glance at the dashboard occasionally, then work site-by-site referring to the badges." Under that pattern, 7 days expires before the next visit.

The client's ask was clean: "I want it visible until the next check." So we bumped TTL to 30 days:

const _DASH_CACHE_MAX_AGE_MS = 30 * 24 * 60 * 60 * 1000;  // 7→30 days

But 30 days is long, so without showing how old the visible number is, users risk treating stale data as fresh. We added an age suffix to the tooltip:

function _formatPendingPluginCountAgeSuffix() {
  const loaded = _updatesDashState.loadedAt;
  if (!loaded) return '';
  const days = _daysSinceTimestamp(loaded);
  return _formatDaysAgoText(days, '（最終取得: ${days}）');
  // → e.g. "(last fetched: 5 days ago)"
}

_formatDaysAgoText is the helper from the elapsed-days badge, reused as-is. Keeping the "N days ago" phrasing in one place makes small reuses like this easy.

Lesson 2 — Pair longer TTLs with explicit freshness

Stretching a TTL increases the risk of staring at stale data. Rather than cutting it shorter to compensate, show the user how stale and let them decide. 30 days + "5 days ago" is more informative than a hard 7-day cutoff.

Pitfall 3 — One site's maintenance wiped every badge

The third pitfall surfaced in real usage: "I ran maintenance on one site, but the badges for other sites are gone too. Is that right?"

The old behavior was "clear the entire dashboard cache on a successful maintenance run":

// Old: wipe everything
function _invalidateUpdatesDashCache() {
  _updatesDashState = { sites: [], total_pending_count: 0, loadedAt: 0 };
  _saveUpdatesDashStateToLocalStorage();
}

This was the same trap we hit in the streaming-log story: if a state clear isn't scoped to the execution, it sweeps up unrelated state. Maintaining one site shouldn't blow away the other nine sites' badges; that's worse than not clearing at all.

The fix takes a list of executed site IDs and does a partial invalidation:

function _invalidatePendingPluginCacheForSiteIds(siteIds) {
  if (!Array.isArray(siteIds) || siteIds.length === 0) return;
  const idSet = new Set(siteIds);
  _updatesDashState.sites = _updatesDashState.sites.filter(
    s => !idSet.has(s.site_id)
  );
  _updatesDashState.total_pending_count =
    _updatesDashState.sites.reduce((sum, s) => sum + s.plugins.length, 0);
  _saveUpdatesDashStateToLocalStorage();
  // Leave loadedAt alone — this is a partial update, the "fetch time" is still valid
}

The caller pulls the executed _ids out of payload.sites and hands them over. When payload.sites === null (a full-site run), we fall back to full clear — so we didn't remove full-clear, we split "explicit clear-all" from "clear-only-these".

The old _invalidateUpdatesDashCache() is kept around (not removed). There may be a legitimate "wipe everything" caller in the future (a manual "clear cache" button, say), and keeping the explicit option around is safer than deleting it.

Lesson 3 — Always scope state-clears to the execution

Same shape as the running-site detection trap. When you write "on maintenance start, reset the cache" — be very careful that the implicit scope isn't "everything." If execution scope varies, take it as an argument and limit the clear to that scope. Small effort, big effect.

Closing — cache-lifetime design comes down to "your reader's lifecycle" and "your clear's scope"

The three pitfalls came from separate reports, but the underlying principles converge:

Restore caches at app boot, period. Tying restoration to the "first consumer" silently breaks when a second consumer is added. DOMContentLoaded + a one-time restore with try/catch defense is the safe default
Pair long TTLs with explicit freshness signals. 30 days + a "fetched N days ago" tooltip carries more information than a hard 7-day cutoff. Showing the staleness lets the user decide
Scope every state-clear to the execution. Don't default to "wipe all." Take the execution-scope ID list as an argument and clear only that. Keep the explicit "wipe all" available as a separate function for cases that legitimately need it

Caches are about speed, but once you're in production, the lifetime design ends up determining the UX more than the speed gain does. Next time we add a cache, the three patterns above — boot-time restore, freshness visualization, scoped invalidation — go in as a template from the start.

A pending-plugin-count badge on the 🔌 button — reusing the dashboard cache instead of doubling state

Susumu Takahashi — Wed, 08 Jul 2026 00:40:22 +0000

A client asked: "After I run a cross-site update check, can each site show — right in the site list — how many plugin updates are still pending?" Visually the answer was obvious: a small red badge on the top-right of the 🔌 plugins button, like an unread-notification count. Easy to specify.

The harder question was where the data comes from. We could have added a fresh API endpoint and a new cache to hold "pending count per site." But doing that would have doubled state management, and we already had a cache that knew this. We routed through the existing one. Here's the reasoning behind that decision.

Reuse the dashboard cache as the data source

The cross-site updates dashboard (the one we wrote about in killing the 24.5-second silence with a cache-first design) already kept each site's pending plugins in a localStorage-backed state called _updatesDashState. Its shape:

_updatesDashState = {
  sites: [
    { site_id: "abc...", plugins: [ {...}, {...}, {...} ] },
    { site_id: "def...", plugins: [ ... ] },
  ],
  total_pending_count: 12,
  loadedAt: 1748600000000,
}

Look up by site_id, take plugins.length, and you have the badge's number. No new API, no new cache. The data that powers the cross-site dashboard is also the data that powers the site-list badge.

The win of not adding state is quiet but real:

When a maintenance run invalidates _updatesDashState, the badge disappears automatically (no sync code to write)
The TTL (originally 7 days; later extended to 30 days with partial invalidation) inherits from the existing design
The badge and the underlying count can't drift — there's no second copy to fall out of step

There's always a temptation to spin up a new endpoint for a new UI element. The rule we settled on: if the existing state answers it, don't add more.

Attaching the badge — consolidate into helpers

Both the list view and grid view need the same badge on the 🔌 button, so the logic lives in helpers.

function _getPendingPluginCountForSite(siteId) {
  // null = unchecked (badge not shown); a number = the actual pending count
  const entry = _updatesDashState.sites.find(s => s.site_id === siteId);
  return entry ? entry.plugins.length : null;
}

function _attachPendingPluginCountBadge(pluginsBtn, siteId) {
  const count = _getPendingPluginCountForSite(siteId);
  if (count === null || count === 0) return;        // reduce noise
  const display = count > 99 ? '99+' : String(count);
  const badge = document.createElement('span');
  badge.className = 'plugin-count-badge';
  badge.textContent = display;
  badge.title = _formatPendingPluginCountTooltip(count);
  pluginsBtn.appendChild(badge);
}

A small but easy-to-miss detail: the button itself needs position: relative; so the absolutely-positioned badge doesn't fly off the parent. Without it, the badge ends up in a corner of the screen.

Thresholds that cut noise

If we showed a badge on every site — including "zero pending" and "never checked" — the site list would turn into a sea of icons. The two cuts we made:

Don't show 0 — a healthy site has no badge. Surfacing danger signals beats surfacing reassurance for an inventory view
Don't show "unchecked" — return null, no badge attached. "I don't know the count" and "the count is zero" mean different things, and the UI should preserve that distinction

For three-digit counts, the layout breaks unless you cap. We use 99+, not 100+ — it keeps the badge width consistent across rows, and it's the convention readers already know from GitHub-style notification counters.

Per-site checks update the badge too

Pulling data only from the cross-site dashboard misses one path: "I clicked the 🔌 on a single site, looked inside, and now I want the badge updated." The request was "either path should refresh the badge," so the per-site check writes back to the same cache.

function _updatePendingPluginCacheForSite(site, plugins) {
  // From /api/site_plugins, keep only "update available" — exclude must-use / dropin
  const pending = plugins.filter(p =>
    p.update === 'available' &&
    p.status !== 'must-use' && p.status !== 'dropin'
  );

  const sites = _updatesDashState.sites;
  const idx = sites.findIndex(s => s.site_id === site._id);

  if (pending.length === 0 && idx >= 0) {
    sites.splice(idx, 1);            // drop the entry entirely when count hits zero
  } else if (pending.length > 0) {
    const entry = { site_id: site._id, plugins: pending };
    if (idx >= 0) sites[idx] = entry;
    else sites.push(entry);
  }

  _updatesDashState.total_pending_count =
    sites.reduce((sum, s) => sum + s.plugins.length, 0);
  _saveUpdatesDashStateToLocalStorage();
  filterSites();                      // immediately re-render the site list
}

The must-use and dropin exclusions matter — those plugins don't go through the standard WordPress update flow, and counting them would create a "badge says update available, but the update button does nothing" bug.

The trailing filterSites() re-renders the site list right then, so the new count is visible before the user even closes the modal. That "yep, it took" feedback is what makes the path feel solid.

Lessons — "if existing state answers it, don't add more"

Three principles to take away:

A new UI element doesn't necessarily need a new data source. The badge displayed "pending count," but that count was already known to the cross-site dashboard. Before adding a new API or cache, check whether existing state can answer the question. If it can, don't add more — you'll save yourself sync code and drift risk
Express noise reduction as thresholds. Hiding the zero and unchecked states means "badge present = needs attention." Showing the badge on every site reduces it to background noise
Make both write paths converge on the same cache. Whether the user updates via the cross-site dashboard or via a per-site check, the same cache is written. That way "I prefer the dashboard" and "I prefer per-site" workflows both end up with correct badges

A site-list badge looks like a small feature, but underneath, the lessons that pay off are about not adding state when you don't have to, picking thresholds that mean something, and converging your update paths. Next time something small needs adding, the cheapest move is to ask: is the answer already in something we have?

One more issue surfaced later: when maintenance ends with an error, the badge disappears even if plugins were left unupdated — because the completion handler assumed "done = zero remaining" and deleted the cache entry. How that assumption broke and the redesign using a backend marker line to sync real counts to the frontend is in When maintenance ends with an error, the plugin update badge disappears.

A "days since last maintenance" badge — color-coding staleness across many sites

Susumu Takahashi — Tue, 07 Jul 2026 00:27:11 +0000

When you maintain a number of WordPress sites, showing the "last maintenance date" in the site list is the obvious move. A column of dates like 2026-05-21. But in actual use, that alone falls short.

A client put it well: "Besides the last maintenance date, it'd help to also show how many days have passed. And it'd be even better if the color changed at 15 / 30 / 60 days so I can see the risk level." This post walks through that step — from "absolute date" to "relative elapsed days + color" — including the small design details.

Why a date alone isn't enough

An absolute date like 2026-05-21 is precise, but it pushes the "difference from today" calculation onto the user's head. Fine for five sites; as the managed set grows, reading "which ones are getting neglected" off a column of dates gets hard.

The point of a maintenance inventory is to grasp which sites need attention at a glance. If so, what you should surface is less the absolute date and more the relative quantity — "how many days since the last maintenance" — and ideally let color convey "how many days until it's risky." The client's request landed exactly on this "absolute → relative + risk" shift.

Four-tier color coding

We went with four tiers by elapsed days. A small badge like (15 days ago) sits right after the last-maintenance date, and the color changes by threshold.

Elapsed	tier	color	meaning
0–14 days	fresh	green	recently maintained, fine
15–29 days	normal	gray	standard
30–59 days	warn	amber	needs attention
60+ days	danger	red	needs action

green → gray → amber → red — just scrolling the list, "lots of red here" or "a cluster of sites I haven't touched lately" jumps out visually. The badge also gets a hover tooltip ("N days since last maintenance") to back up the number's meaning.

Consolidate into helper functions

The display logic is called from multiple places (list view, grid view), so scattering inline day calculations would be a DRY violation. We consolidated into a set of helpers.

// Returns elapsed days. null for empty/invalid input, future dates clamped to 0
function _daysSinceLastRun(lastRunStr) {
    if (!lastRunStr) return null;
    // Safari compat: normalize "YYYY-MM-DD" to "YYYY/MM/DD" before Date
    const normalized = lastRunStr.replace(/-/g, '/');
    const d = new Date(normalized);
    if (isNaN(d.getTime())) return null;
    const diffMs = Date.now() - d.getTime();
    const days = Math.floor(diffMs / 86400000);
    return days < 0 ? 0 : days;  // clamp future dates to 0 (clock-skew defense)
}

// Returns a color object by threshold
function _daysAgoStyle(days) {
    if (days <= 14) return { tier: 'fresh',  color: '#15803d', bg: '#dcfce7' };
    if (days <= 29) return { tier: 'normal', color: '#4b5563', bg: '#f3f4f6' };
    if (days <= 59) return { tier: 'warn',   color: '#92400e', bg: '#fef3c7' };
    return                 { tier: 'danger', color: '#7f1d1d', bg: '#fee2e2' };
}

Three "small but worthwhile" defenses are baked in.

Safari-compatible date normalization

new Date("2026-05-21") works in Chrome, but Safari can return Invalid Date depending on environment — a known quirk where Safari doesn't reliably parse hyphenated YYYY-MM-DD. Replacing hyphens with slashes to 2026/05/21 before passing to Date parses stably in Safari too. If you're not pulling in a date library, normalizing up front is the safe path for cross-browser date parsing.

Future-date clamping (clock-skew defense)

If the server and client clocks disagree, or a maintenance date somehow lands in the future, elapsed days go negative. A (-3 days ago) display is nonsense, so days < 0 ? 0 : days clamps to zero — treating it as "today." An edge case, but the kind that screams "this is broken" the moment it shows.

i18n fallback

The elapsed-days text generates Today / 1 day ago / N days ago through i18n. The trap here: if rendering runs before the i18n keys load, raw keys like site_list.days_ago_n show up on screen verbatim.

function _formatDaysAgoText(days) {
    // Reference _i18n directly, fall back to English if unregistered
    if (days === 0) return _i18n?.days_ago_today ?? 'Today';
    if (days === 1) return _i18n?.days_ago_one   ?? '1 day ago';
    const tmpl = _i18n?.days_ago_n ?? '${days} days ago';
    return tmpl.replace('${days}', days);
}

The ?? 'fallback' guarantees meaningful text regardless of i18n load timing. The lesson: any dynamically generated text needs a fallback that accounts for the i18n initialization race.

Lock the color thresholds with regression tests

The thresholds (14 / 29 / 59 / 60+) are the spec, so we locked them with regression tests. tests/test_days_since_last_run.py has 18 cases — whether the four-tier boundaries (14 vs 15, 29 vs 30, 59 vs 60) return the right tier, the null / NaN / future-clamp defenses, Safari normalization, that both list and grid views call the helpers, and that no old inline calculation remains (DRY-violation detection).

The boundary tests matter most. Off-by-one errors like "is 30 days warn or normal" are easy to miss reading the spec alone, and without test-locking they drift silently in a future refactor.

Closing — "relative quantity + risk" beats "absolute value"

Three principles from this round:

Inventory UIs should show relative quantity over absolute value. "(15 days ago)" offloads the user's mental math better than "last maintained 2026-05-21." Add color for risk and the sites that need attention rise out of the list as you scroll
Build cross-browser defenses into date parsing from the start. Safari's YYYY-MM-DD issue and future-date clamping are the kind of thing that, addressed after the fact, leaves you debugging "can't reproduce, environment-dependent." Normalize and clamp from day one
Always attach an i18n fallback to dynamically generated text. The "raw key shows on screen during the i18n load race" bug is structurally prevented by a ?? 'fallback'

Inside the modest feature "show a date" sat several quiet design decisions — relative-time presentation, cross-browser date parsing, the i18n race, boundary tests. For an admin screen spanning many sites, translating "when" into "how many days until it's risky" lowers the effort of spotting what needs attention and makes it easier to head off missed maintenance.

Detecting the running site from streaming logs — why log-order inference broke, and how one marker fixed it

Susumu Takahashi — Mon, 06 Jul 2026 01:40:06 +0000

In a screen that runs maintenance across multiple sites in sequence, you want to show progress live: a blue border on "the site being processed now," a green border on "completed sites." Common UI.

The approach we reached for first was "watch the streaming logs the backend emits, and infer which site is being processed." It turned out to be surprisingly tricky — three rounds of fixes before it stabilized. This post records that trial-and-error as a design log.

The first design — "site switched, so mark the previous one done"

Logs arrive per-site as lines like [Site name] Starting maintenance. The first implementation was simple:

// Initial implementation (later found to be the root of the bugs)
function _setRunningSiteId(siteId) {
    if (_runningSiteId && _runningSiteId !== siteId) {
        _markCompleted(_runningSiteId);  // switched to another site = previous is done
    }
    _runningSiteId = siteId;
}

The inference: "a new site name appeared in the log = the previous site finished." Intuitively plausible.

Bug 1 — log "rewind" marks an unstarted site as done

Real-world testing surfaced this: "select two sites, run, and the second site that hasn't even started yet turns green (done)."

The cause was that the streaming log sometimes interleaves multiple site names in a non-monotonic order.

t1: log shows [Site A]        → _runningSiteId = A
t2: log shows [Site B]        → mark A done + _runningSiteId = B
t3: log shows [Site A] again  → mark B done + _runningSiteId = A

At t3, B — which hasn't started processing — gets falsely marked "done." The "switched, so previous is done" rule was fragile against the log's non-monotonic ordering.

Fix 1 — reject rewind with an execution-order index

On run, we save the "planned site ID array (in execution order)" and ignore any switch whose index moves backward.

let _runningSiteIdOrder = [];   // planned site_id array (execution order)
let _runningSiteIdIndex = -1;   // current index

function _setRunningSiteId(siteId) {
    const newIdx = _runningSiteIdOrder.indexOf(siteId);
    if (newIdx < _runningSiteIdIndex) {
        return;  // rewind = ignore (e.g. index=0 log reappears while index=1 is running)
    }
    _runningSiteIdIndex = newIdx;
    _runningSiteId = siteId;
}

We also moved completion marking off the switch event entirely — completion now gets applied to the whole execution-order array at the end of the run. We separated "inferring what's running" from "confirming what's done."

Bug 2 — the real root cause was the init loop's pre-emitted logs

Even with rewind defense, another failure recurred: "A is running, but B shows as running."

Scrutinizing the logs revealed the real root cause. The backend (maintenance_agent.py) was emitting init logs for all target sites before any actual maintenance processing began:

[Site A]   Injecting connection info from SSH profile
[Site B]   Injecting connection info from SSH profile
[Site C]   Injecting connection info from SSH profile
[Site A]   Starting maintenance   ← actual processing begins here
[Site A]   Creating backup
...

The old detection logic picked candidates from "every line containing [...]," so it falsely detected the last site in the init loop (C, the last injection log) as "running." That was the real story behind "A is running but B/C show as running." Rewind defense helped the ordering problem, but was powerless against "we're reading the wrong lines in the first place."

Fix 2 — the marker approach (narrow to one line type)

The fix was almost anticlimactically simple. Detect only the "Starting maintenance" line, which appears exactly once at the start of each site's real processing.

const _START_MARKER = /メンテナンスを開始|Starting maintenance/;

function _detectRunningSiteFromLog(lines) {
    for (let i = lines.length - 1; i >= 0; i--) {
        if (!_START_MARKER.test(lines[i])) continue;  // ignore non-marker lines
        const siteName = extractBracketName(lines[i]);
        // ... match against allSites, then _setRunningSiteId
        return;
    }
}

Init lines like [Site B] Injecting SSH profile are now completely ignored; _runningSiteId only moves the instant [Site A] Starting maintenance appears. The shift was from "infer state from the whole log" to "pick one clear marker that represents a state transition, and watch only that."

Bug 3 — the completion reset was too aggressive

The last one is smaller. We had a "clear all completion marks (green borders) when a maintenance run starts" step, but a user pointed out: "shouldn't sites maintained within the last 24 hours stay green?"

Right — we should have reset only the sites in the current run's scope, but we were also wiping the green borders of out-of-scope sites (ones recently maintained on a different occasion). Limiting the reset to the execution scope fixed it. A "clear state" step always needs its clear-scope kept in mind, or it sweeps up unrelated state.

Lessons — inferring state from streaming logs

Three principles from three rounds of fixes:

Don't infer state from the whole log — pick one clear marker. Loose inference like "a name appeared = it's running" is fragile against non-monotonic log output (pre-emitted init logs, interleaved names). A one-to-one "this line means this state" marker removes the inference ambiguity
Separate "inferring what's running" from "confirming what's done." Marking the previous site done at switch time means a mis-detected switch also mis-marks completion. Confirming completion in one batch at run-end keeps it out of the inference jitter
Always scope your state clears. "Reset everything" is easy, but it sweeps up unrelated state. Limit the clear to the execution scope

Behind the modest request "show progress live" lurked the difficulty of inferring state from an asynchronous data source. When you're wiring up "watch logs, reflect state in the UI," building with the marker approach from the start is the shortcut that avoids three rounds of rework.

Quieting PHP 8.2+ deprecated noise from older WP-CLI — three layers to keep JSON parse clean

Susumu Takahashi — Sat, 04 Jul 2026 21:46:16 +0000

Our multi-site maintenance tool fires wp plugin list --format=json against the sites it manages. One day, against a specific shared host (Xserver in Japan), this call started failing — and the failure mode was unusually subtle.

Both the SSH connection test and the WP-CLI path test (wp --version) came back green. Users saw "all diagnostics pass, but the actual operation fails," a frustrating asymmetry. Tracing it back, the root cause was PHP Deprecated warnings emitted by older WP-CLI (2.x) under PHP 8.2+ leaking into the JSON output.

This post walks through the three-layer defense we used to structurally absorb the noise without losing real failures.

What was happening — Deprecated warnings on stdout

The raw output on a problem host looked like this:

PHP Deprecated:  Creation of dynamic property
WP_CLI\Dispatcher\CompositeCommand::$longdesc is deprecated
in phar:///usr/bin/wp/vendor/wp-cli/wp-cli/php/...
[
  {"name":"akismet","status":"active","update":"none", ...},
  ...
]

Since PHP 8.2, assigning to a dynamic property on a class without #[\AllowDynamicProperties] emits a Deprecated warning. Xserver's /usr/bin/wp (an older WP-CLI 2.x) leans on dynamic properties internally, so running it on PHP 8.2+ produces a steady stream of those warnings.

Note: PHP 8.2's dynamic-property deprecation is a healthy direction for the language. But during the transition, you get many libraries that "warn but still work" — WP-CLI was one of them.

The actual problem is the host's php.ini: depending on display_errors, those warnings end up on stdout instead of stderr. Calling wp plugin list --format=json returns stdout containing both the warnings and the JSON, and json_decode() fails on the mixed input.

Why diagnostics stayed green but operations failed

The frustrating asymmetry came from how each test was checking the output:

SSH connection test: runs echo ok — passes as long as ok appears somewhere in stdout, extra lines are fine
WP-CLI path test: runs wp --version — passes as long as a version string is found
Real operation: runs wp plugin list --format=json — the JSON parse step is the only place the noise actually matters

To the user it looks like "all my tests are green, but the real call fails." If your diagnostics only check exit code and "did the expected substring appear," anything that surfaces only at the structured-output stage slips through silently. This is the same shape as the trap we hit with SSH commands failing on csh login shells — single commands pass while structured workflows break.

Three layers of defense

You can try to suppress the warnings entirely, but you can't fully predict every host's php.ini configuration — so we built multiple independent layers that each catch a different leakage path.

Layer 1 — `WP_CLI_PHP_ARGS` to silence warnings at the source

WP-CLI exposes an environment variable WP_CLI_PHP_ARGS that gets forwarded to the underlying PHP invocation. We set it to mask Deprecated entries via error_reporting:

_WP_CLI_PHP_QUIET_ARGS = (
    "-d error_reporting='E_ALL & ~E_DEPRECATED & ~E_USER_DEPRECATED'"
)

def _wp_with_quiet_php(wp_cli_path: str) -> str:
    """Wrap a WP-CLI call with WP_CLI_PHP_ARGS to suppress Deprecated warnings."""
    return (
        f"WP_CLI_PHP_ARGS={shlex.quote(_WP_CLI_PHP_QUIET_ARGS)} "
        f"{wp_cli_path}"
    )

shlex.quote keeps the value safely escaped for the shell, and the function plays nicely with our existing per-site WP-CLI path override feature. Parse and Fatal errors still surface — only Deprecated/Notice-level noise gets quieted.

Layer 2 — strip noise lines before JSON parse

Layer 1 cleans up most environments, but if the host overrides error_reporting again at runtime (php.ini -> ini_set() chain), warnings can still slip through. As defense in depth, we strip recognized noise lines from stdout before parsing.

_PHP_NOISE_LINE_RE = re.compile(
    r'^\s*PHP\s+(Deprecated|Warning|Notice|Strict Standards):.*$',
    re.MULTILINE | re.IGNORECASE
)

def _strip_php_noise(text: str) -> str:
    """Remove PHP Deprecated/Warning/Notice/Strict Standards lines from stdout.
    Parse error / Fatal error are NOT stripped — those are real failures
    the user should see."""
    return _PHP_NOISE_LINE_RE.sub('', text)

The deliberate omission of Parse error and Fatal error matters. Those mean the operation actually broke, and the user needs to see them. The regex enumeration of four noise categories draws the line cleanly between "annoyance" and "actual failure."

Layer 3 — try JSON even when exit code is nonzero

Layers 1 and 2 catch most cases, but a small number of hosts return exit code 1 just because of warnings while leaving valid JSON in stdout. Fabric (paramiko) reports res.ok = False, but the parseable data is right there.

stdout_clean = _strip_php_noise(res.stdout or '').strip()
plugins = None
if stdout_clean:
    try:
        plugins = json.loads(stdout_clean)
    except json.JSONDecodeError:
        plugins = None

if plugins is None:
    # Only here do we conclude "no JSON" — fall to error
    if not res.ok:
        return error_response(res.stderr or res.stdout)

The trick is try JSON before trusting the exit code. If stdout contains a valid structure, treat the call as successful even with a nonzero exit.

Spread the fix across all three APIs at once

Same principle as V12 (the csh portability bug): when you find this kind of issue, grep for the same pattern across the codebase and fix everywhere at once. The plugin-list fetch lived in three call sites:

/api/fetch_plugins — the cross-site plugin dashboard
/api/site_plugins — the per-site plugin list modal
_do_fetch_pending_plugins_for_site — the maintenance-time pending-update scan

All three were rewritten to use _wp_with_quiet_php + _strip_php_noise + JSON-first parsing. Fixing only one would have left the same regression alive on a different path.

For regression defense, tests/test_wp_cli_php_noise.py ships with 18 cases (noise-line removal, Parse error preservation, env-var formatting, shlex quoting, compatibility with per-site WP-CLI path override, and presence checks for all three APIs). If anyone later adds a fourth API that calls json_decode directly on raw c.run output, the CI fails.

Closing — "warning-level differences × structured output"

Three principles worth keeping from this round:

Diagnostics green / production red is structurally easy to produce. Most tests check "did the command run and produce expected substrings" — structured-output paths see the noise that simple-string paths don't. Add one structured-output parse step to the diagnostics to catch this class of bug early
Layer noise suppression in independent steps. Source suppression (error_reporting) / line filtering / exit-code bypass are independent defenses. Stack them, and a hosting quirk that defeats one layer still gets caught by another. You can't fully predict host configurations — layering is the answer
Distinguish noise from real failures by regex. Deprecated / Warning / Notice / Strict Standards are safe to strip; Parse error / Fatal error must always pass through. "Just hide all the warnings" hides the real failures too — enumeration with a tight regex draws the right line

When you're invoking environment-sensitive CLI tools like PHP / WP-CLI from a maintenance tool, similar bugs are probably sitting under the surface. The "error_reporting suppression + noise-line stripping + JSON-first parse" template is a reusable pattern worth keeping in the toolbox.

Implementing a dynamic OGP image generator for our blog — PHP GD, per-post 1200 630 cards

Susumu Takahashi — Fri, 03 Jul 2026 23:03:58 +0000

One day on our English X account, I posted a link to a fresh blog article and froze when the OGP card rendered: the image was the LP sales banner — "Stop babysitting updates. Start scaling maintenance revenue." — not anything related to the post itself.

Going back through the last seven announcement posts, every single one was showing the same LP sales banner. Articles written as technical engineering deep-dives had been quietly flowing through the X timeline for months looking like sales-promo posts.

This article walks through how we found the structural cause and replaced it with a dynamic OGP image generation engine — using our own blog as the example.

The structural cause — "no featured image → LP default"

Digging in, the theme's OGP logic was a classic fallback: "if there's a featured image use it, otherwise the LP default." The problem was that none of our 21 articles × 2 languages = 42 posts had a featured image. Every post was returning the same LP sales banner as og:image.

Note: OGP (Open Graph Protocol) is the metadata SNS clients use to render link previews. X, Facebook, LinkedIn, Slack and others all read og:image and friends.

Two options — manual artwork vs dynamic generation

Two repair paths were on the table.

Option A. Manually set a featured image on all 21 posts. Honest answer, but (1) producing 42 images once is heavy, (2) every new article afterward inherits an ongoing artwork cost, and (3) the "Japanese style" stock photos (PCs, keyboards, abstract code) read as amateur to international tech audiences, which works against us

Option B. Build a dynamic OGP image generator. The international tech-blog standard pattern. Vercel, PlanetScale, dev.to and friends all generate black-background + headline-composed OGP cards on demand — render once, cache, and every new post automatically inherits a per-article OGP

We picked Option B:

One engine, then 21 posts (and every future post) auto-resolve correctly
"Black + title" composition is the visual register international tech readers expect
"Find a stock image for every article" stops being a step

The core — `ogp-generator.php` (PHP GD, ~375 lines)

PHP GD (the image-manipulation library shipped with PHP) renders the 1200×630 PNG on demand. Everything sits in one standalone PHP file, ogp-generator.php.

// ogp-generator.php (sketch)
$post_id = (int)($_GET['post_id'] ?? 0);
$cache_path = WP_CONTENT_DIR . "/uploads/ogp/post-{$post_id}.png";

// 2nd hit onward: serve from disk cache
if (file_exists($cache_path)) {
    header('Content-Type: image/png');
    readfile($cache_path);
    exit;
}

// First hit: pull title from WP DB
$post = get_post($post_id);
$title = $post->post_title;

// Render 1200×630 PNG via GD
$im = imagecreatetruecolor(1200, 630);

// Background #0d1117 (LP main dark)
$bg = imagecolorallocate($im, 0x0d, 0x11, 0x17);
imagefilledrectangle($im, 0, 0, 1200, 630, $bg);

// Top blue 4px / bottom green 4px (visual continuity with LP)
$blue  = imagecolorallocate($im, 0x2f, 0x81, 0xf7);
$green = imagecolorallocate($im, 0x3f, 0xb9, 0x50);
imagefilledrectangle($im, 0, 0, 1200, 4, $blue);
imagefilledrectangle($im, 0, 626, 1200, 630, $green);

// Title text (font picked by language)
$font  = has_japanese($title) ? NOTO_BOLD : INTER_BOLD;
$lines = wrap_text($title, $font, 56, 900);
$y = 220;
$white = imagecolorallocate($im, 0xff, 0xff, 0xff);
foreach ($lines as $line) {
    imagettftext($im, 56, 0, 100, $y, $white, $font, $line);
    $y += 88;
}

// Cache to disk and serve
imagepng($im, $cache_path);
header('Content-Type: image/png');
readfile($cache_path);

Nothing fancy, but the key components are all there. The first request renders; every request after that streams the cached PNG from disk — the GD cost is paid exactly once per post.

Japanese titles need a second font — Inter + Noto Sans JP

The first thing that broke was the fact that Inter has no Japanese glyphs at all. It's a Latin-script-only font; the JIS X 0208 range doesn't exist. Passing a Japanese title through imagettftext() with Inter produces tofu (□□□) or nothing.

The fix: detect whether the title contains Japanese and swap fonts.

function has_japanese(string $text): bool {
    return preg_match('/[ぁ-んァ-ヶ一-龯]/u', $text) === 1;
}

We bundled Noto Sans JP Bold (SIL Open Font License, 5.1 MB) and Inter Bold / Regular (same SIL OFL, ~325 KB each) into the theme assets and rsync them alongside the other theme files.

The `functions.php` patch — `+28 / -2`

The OGP logic redirects through the dynamic URL when there's no featured image. The diff is small (+28 / -2), and the existing behavior (posts with a real featured image keep using it) is preserved.

// After: posts without a featured image return the dynamic URL
function wpmm_blog_og_image($post) {
    if (is_singular() && !has_post_thumbnail($post)) {
        $cache_bust = date('YmdHis');
        return home_url(
            "/wp-content/themes/wpmm-blog/ogp-generator.php" .
            "?post_id={$post->ID}&v={$cache_bust}"
        );
    }
    // Posts with a featured image still take precedence
    $thumb = get_the_post_thumbnail_url($post, 'full');
    return $thumb ?: LP_DEFAULT_OGP;
}

&v=YYYYMMDDHHMMSS is a cache-busting query string. When we update the theme and change the OGP design, this forces X and Facebook to re-crawl rather than serving their stale cached image.

Design decisions and the result

The canvas is 1200×630 (OGP standard, X large-image-card recommended). Background #0d1117, accent blue #2f81f7 / green #3fb950 are pulled from the LP brand palette; thin 4px blue (top) / green (bottom) bars give visual continuity with the LP. "WP MAINTENANCE MANAGER" top-left, headline center-left, supporting URL bottom-right. The whole composition is intentionally close to what Vercel's og API and PlanetScale's OGP cards look like — visual signals readers associate with proper engineering blogs.

After deploy, curl -I against all 42 og:image URLs confirmed every one was now serving the dynamic URL. On X TL the visual flipped from "LP sales banner" to "dark card with the post title." Retroactively re-posting old announcements isn't worth it since they're past their relevance window — instead we'll be tracking engagement deltas between "LP-image era" and "dynamic OGP era" as ongoing signal.

Closing — four principles for dynamic OGP

Four takeaways worth keeping from this round:

WP theme OGP defaults can quietly produce "every post has the same image." The classic if (no_thumb) return LP_DEFAULT fallback is well-meaning, but combined with a workflow that doesn't set featured images it becomes one identical sales banner across every post. Audit og:image across all posts periodically — a curl -I sweep of 42 URLs takes seconds
Manual artwork is both a workload tax and a tone hazard. Beyond the ongoing labor, "regional visual signals" matter — Japanese-style stock photography reads as amateur to international tech audiences. Dynamic generation sidesteps both
PHP GD + WP DB + disk cache is a one-file, lightweight stack. Lighter than it sounds. First-render GD pass, then static file serving — per-request load is essentially zero after the first hit. You don't need an edge runtime like Vercel's to do this
Japanese fonts trip you up at the first hour. Latin-only fonts like Inter / Roboto turn Japanese titles into tofu. Build language detection + Noto Sans JP into the path from day one

This article ended up being a meta piece about our own blog's OGP, written for our blog — and naturally this very post now has a dynamic OGP card generated by the engine it describes. Worth checking your own blog's og:image if you're running one — similar regressions can sit under the surface for months without anyone noticing.

Diff from the live server, not from your git history — when a local repo has drifted from production

Susumu Takahashi — Fri, 03 Jul 2026 00:26:38 +0000

An investigation agent flagged "the license API PHP returns Japanese-hardcoded messages" and we sat down to fix it. But something felt off the moment we opened the file — the version running on the production server didn't match the latest commit in the local repo. Stranger still, production had more recent features than our local checkout.

A bit of digging turned up the truth: months earlier, someone had hot-patched the production file in response to a different user issue, and that change had never been committed back to git. This post walks through how we detected that drift, and the two-stage strategy we used to merge production back into the local repo safely.

How this regression silently slips in

If we'd written the fix on top of our local repo and uploaded it to production, here's what would have happened: all the production-only improvements get overwritten and quietly disappear.

In our case, the production file had a half-year-old language-handling addition for the "Early Bird Bonus" feature — when a USD customer buys, client_name is set to 'Early Bird Bonus'; for JPY customers it's '早期利用特典'. None of that existed in our local git. A normal PR-merge-and-deploy cycle would have silently rolled back the Early Bird i18n logic, regressing English users' display back to Japanese.

Catching this was half luck. Opening the file to start the fix, I noticed code I didn't recognize, ran git blame, and the lines were nowhere in git history. That's when alarm bells went off.

Two-stage rollforward — make production the source of truth first

The strategy we landed on was a two-stage merge.

Stage 1 (rollforward sync): Pull the production file straight into the local repo. Apply the diff in the "production → local" direction, not the other way. After this, the local repo's HEAD matches what's actually running on production.

# Pull the production file into the local repo
scp -i ~/.ssh/key layer2024@host:wpmm.jp/public_html/license/api/register_free.php \
    /tmp/register_free_prod.php

# Record its MD5 first (we'll need this later for upload verification)
md5 /tmp/register_free_prod.php
# → 94b9c5a7...

# Replace local file with the production copy, then commit
cp /tmp/register_free_prod.php server/wpmm-license/api/register_free.php
git add server/wpmm-license/api/register_free.php
git commit -m "rollforward sync: pull v1.5.9 hotpatch from production"

The key move here is "commit the production state as a separate commit, before doing any feature work" — that single rollforward commit makes every subsequent diff a clean delta against production reality.

Stage 2 (additive): With the local repo now in sync, add only the new functionality as a follow-up commit. Don't touch any existing code in the Early Bird section.

# Build the stage-2 commit
# - Keep the existing Early Bird block (lines 71-111) byte-for-byte
# - Add only the new lines (i18n fallback, lang query addition)
git diff HEAD~1 -- server/wpmm-license/api/register_free.php
# Eyeball the output: confirm zero deletion lines

"Zero deleted lines" is a mechanical safety check you can apply. The diff's structure itself guarantees you're not changing production behavior, just extending it.

Use MD5 to prove byte-for-byte preservation

If you're going to claim "byte-for-byte unchanged," prove it quantitatively. Before and after upload, we md5-hashed the preserved section to be sure.

# Hash just the preserved section (Early Bird, lines 71-111)
sed -n '71,111p' server/wpmm-license/api/register_free.php | md5
# Expected: matches the same range in the original production file

# Verify again after upload
ssh user@host 'sed -n "71,111p" wpmm.jp/.../register_free.php | md5'

INSERT INTO licenses statement, bind order, $client_name_label = $is_en ? 'Early Bird Bonus' : '早期利用特典' ternary, try/catch, period logic — all of it can be confirmed structurally unchanged. The hash check is mechanical proof.

Closing — "my git history is canonical" is a dangerous assumption

Three principles worth keeping from this round:

Make "diff from the live server" a habit before starting work. Your local git is not necessarily the latest truth. Especially in projects with a hot-patch culture, production may carry changes that aren't in your repo. Always scp the production file and diff against local before touching it
When you find drift, merge in two stages. Stage 1 ("rollforward sync") makes production the source of truth in your repo. Stage 2 ("additive") layers new features on top. Splitting the merge this way structurally prevents "regressing production improvements"
Verify preservation with md5, not just words. Don't just write "this section is unchanged" — extract the preserved range with sed -n, hash it, and confirm before/after upload. Combined with the "zero deletion lines" diff check, you get two independent guarantees

The big lesson from this round was the principle of "always suspect that the local repo has drifted from production." In projects with manual deployment or hot-patch traditions, this is a hard reality to escape. If you've gotten into the habit of treating git as the latest truth, a regression like this one is waiting to happen.

A one-minute scp and diff before starting can save hours of incident response later. Worth building into the muscle memory.

Multilingual emails from a Stripe webhook — inferring language from currency

Susumu Takahashi — Wed, 01 Jul 2026 23:39:06 +0000

A subtle trap of taking a SaaS international: the system emails sent from your Stripe webhook. Purchase confirmation, renewal success, payment failure, plan change — four kinds of emails triggered by Stripe events. We recently discovered all four had been hardcoded to Japanese for months, sending Japanese receipts and failure notices to English-paying users overseas. The kind of bug that quietly persists forever unless you go looking.

This post walks through the currency-based language inference design we landed on, plus the small mb_language trap that nearly ruined the fix.

Where do you get "the user's language" from? — three options

There were essentially three design options for picking the email language inside the webhook:

Option A. Keep a language column in the DB. The classical answer — store language at signup, look it up when sending mail. But it requires a DB migration, leaves existing users in "language unknown" until backfill, and you still need fallback inference for the first email anyway

Option B. Pull from the Stripe API. stripe.Customer.retrieve() exposes preferred_locales. Authoritative in theory, but adds a round trip per send, and not every customer has it set

Option C. Infer from the Stripe event's currency field. Always present in the webhook payload (usd / jpy / etc.). No extra API call, no DB migration, applies to existing users immediately

We picked Option C, because:

Currency is a strong, fixed-at-purchase signal — it doesn't change later
It's already in the payload, so the cost is zero
Zero DB touches means low regression risk on deploy
Existing users get the new behavior automatically (no migration script)

Implementing `lang_from_currency`

The whole helper is this one function:

/** Infer display language from a Stripe event's currency. */
function lang_from_currency(string $currency): string {
    $en_currencies = ['usd'];   // USD → English user
    return in_array(strtolower($currency), $en_currencies, true) ? 'en' : 'ja';
}

USD means English; everything else (including JPY) means Japanese. EUR or GBP can be added to $en_currencies later when those markets open.

It's a "good enough" approximation, but it works in practice: there are essentially no English speakers buying in JPY, and the rare Japanese speaker on a USD plan ends up with English emails — which is more correlated to their explicit purchase intent than something like a browser Accept-Language header.

Pulling `currency` from the four webhook events

The four Stripe events have slightly different payload shapes, so currency lives in slightly different places:

// 1. checkout.session.completed — purchase confirmation
$checkout_lang = lang_from_currency($session['currency'] ?? 'jpy');
send_license_email($email, $client_name, $key, $plan, $period, $checkout_lang);

// 2. invoice.payment_succeeded — renewal success
$renewal_lang = lang_from_currency($invoice['currency'] ?? 'jpy');
send_renewal_email($email, $client_name, $plan, $renewal_lang);

// 3. invoice.payment_failed — payment failure
$failed_lang = lang_from_currency($invoice['currency'] ?? 'jpy');
send_payment_failed_email($email, $client_name, $plan, $failed_lang);

// 4. customer.subscription.updated — plan change
//    (currency reached via the subscription object)
$changed_lang = lang_from_currency($sub_currency);
send_plan_changed_email($email, $client_name, $old_plan, $new_plan, $changed_lang);

The ?? 'jpy' fallback is insurance: if a test event somehow lacks currency, the function returns ja rather than throwing.

The subject-encoding trap — `mb_language('uni' or 'Japanese')`

This is where it gets sneaky. PHP's mb_send_mail() encodes the subject according to whatever mb_language() is set to:

mb_language($lang === 'en' ? 'uni' : 'Japanese');

mb_language('Japanese') encodes the subject in ISO-2022-JP via MIME (JIS X 0208-based, Japan-specific)
mb_language('uni') encodes the subject in UTF-8 Base64 (strict RFC 2047 compliance)

Why does it matter? If you leave mb_language('Japanese') in place and send an English subject like "Your license key for WP Maintenance Manager", the subject gets ISO-2022-JP MIME-encoded — and Gmail and Outlook's spam scoring goes up. Non-Japanese mail clients see a strange-looking encoded subject for what should be plain English text.

The fix is simple — flip mb_language() based on $lang in all four mail functions:

function send_license_email($email, $client_name, $key, $plan, $period, $lang = 'ja') {
    mb_language($lang === 'en' ? 'uni' : 'Japanese');
    // ... subject / body below branch on $lang
}

mb_language('uni') is available since PHP 7.2 (RFC 2047 compliant Base64 UTF-8). If you're handling Stripe webhooks and going multilingual, this is more or less mandatory knowledge.

The win of a no-DB-migration design

The net of this round: the database was not touched. The entire change lives in one file, webhook.php, with one new helper function lang_from_currency. New users get the right language obviously, but existing users who bought months ago also get their next renewal email in the right language, automatically.

This is what a stateless event-driven architecture combined with a strong inference signal can buy you. A DB-state design would have required a backfill pass over historical users — and rows that got missed during backfill would have stayed wrong forever.

Closing — three patterns for webhook i18n

Three principles worth keeping from this round:

If the event payload carries a strong signal, skip the DB. Currency is a fixed-at-purchase signal that's already in every Stripe event. Routing logic through that signal beats a DB-state design when the data is already available — fewer moving parts, less maintenance overhead
Set mb_language('uni') for non-Japanese subjects. ISO-2022-JP MIME encoding of English subject lines is a quiet contributor to spam-score creep. If you support both languages, switch encoding based on the user's language
For multilingual coverage, suspect "is anything still hardcoded?" first. "Four mail functions were all hardcoded to Japanese" is the kind of bug that only surfaces when someone goes looking. Make every Stripe-event-handling function take an explicit language parameter in its signature, so adding a new event forces the author to think about language

If your SaaS is international, "we've been sending Japanese emails to English-paying users" is the kind of failure that doesn't surface until you check. Inferring language from currency at the webhook layer is a one-file, one-helper pattern that closes most of those leaks at a remarkably low cost.

Maintaining WordPress sites behind HTTP Basic auth — Playwright, urllib, and encrypted credentials

Susumu Takahashi — Wed, 01 Jul 2026 00:56:50 +0000

It's pretty common to throw a layer of HTTP Basic auth on a WordPress site: a staging environment before launch, an internal test instance only employees should see, or any environment that wants an extra gate before the WordPress login screen itself.

From a maintenance-tool point of view, this setup creates a peculiar "half-working, half-broken" asymmetry. The SSH/WP-CLI side runs fine. But everything HTTP-based — visual checks, thumbnail generation, browser-based fallback updates — hits 401 and dies. This post walks through how we resolved that asymmetry.

What was breaking — two parallel paths, both blocked

A maintenance tool actually touches a Basic-auth-protected site through two distinct paths:

Playwright path: visual checks, thumbnail capture, browser fallback updates when SSH isn't available. browser.new_context() → navigation → screenshot
urllib path: HTTP status checks (pre/post-update 200/5xx/4xx monitoring, rollback decisions)

With no credentials, both paths see a 401 Unauthorized from the protected site.

The Playwright symptom is the obvious one: the screenshot you save is the browser's "authentication required" dialog. The thumbnail grid fills with dark auth-prompt images, and you start wondering whether anything actually works.

The urllib symptom is much worse — it silently breaks rollback decisions. A 401 baseline followed by another 401 after the update looks like "nothing changed = healthy." Real failures can hide behind that match, and the rollback that should have fired never does.

The design — consolidate credential extraction into one helper

When the same credentials need to flow through multiple code paths, picking them out of the site dict separately at each call site invites format-mismatch and missed-update bugs. So the first thing we did was build a small core/basic_auth_utils.py module that owns every form of credential extraction.

# core/basic_auth_utils.py
def get_basic_auth_tuple(site):
    """Return (user, password), or None if not configured."""
    if not isinstance(site, dict):
        return None
    user = (site.get('basic_auth_user') or '').strip()
    pw = site.get('basic_auth_password') or ''
    if not user:
        return None  # No user → treat as "no auth"
    return (user, pw)

def get_playwright_http_credentials(site):
    """Returns dict for Playwright's new_context(http_credentials=...)."""
    auth = get_basic_auth_tuple(site)
    if auth is None:
        return None
    return {'username': auth[0], 'password': auth[1]}

def get_basic_auth_header(site):
    """Returns {'Authorization': 'Basic <base64>'} for urllib."""
    auth = get_basic_auth_tuple(site)
    if auth is None:
        return {}
    raw = f"{auth[0]}:{auth[1]}".encode('utf-8')
    encoded = base64.b64encode(raw).decode('ascii')
    return {'Authorization': f'Basic {encoded}'}

The key idea: both the Playwright and urllib forms derive from the same get_basic_auth_tuple() root. Format drift between the two callers becomes structurally impossible.

Backward compatibility — existing sites don't have these fields

A small but important detail: the existing site-configuration JSON has no basic_auth_user / basic_auth_password keys. Naively writing site['basic_auth_user'] would crash with KeyError the moment someone opens an existing site.

We went with the site.get('basic_auth_user') or '' empty-string-fallback pattern. Missing key, empty string, or None all collapse to "no auth," so existing sites behave exactly as before. Only the sites that actually set Basic auth flip into the authenticated path.

On top of that, the Basic auth password gets the same treatment as the WordPress admin password: Fernet-encrypted at rest. Adding 'basic_auth_password' to the ENCRYPTED_SITE_KEYS constant is all it takes — encryption and decryption happen automatically on save and load.

Wiring both paths

With the helpers in place, the call sites get rewired.

Playwright path: one shared helper _new_context_with_auth(browser, site) replaces three new_context() call sites (visual check, thumbnail capture, browser residual update) at once.

def _new_context_with_auth(browser, site):
    http_credentials = get_playwright_http_credentials(site)
    if http_credentials:
        return browser.new_context(http_credentials=http_credentials)
    return browser.new_context()

urllib path: _http_status_check(url, basic_auth=None) gains a basic_auth parameter and sends the Authorization header internally. The "baseline 401 → post-update 401" false negative disappears — the rollback decision now sees the real status code after authentication (200 / 5xx / etc.) and fires correctly.

Inside the maintenance main loop run_ssh_maintenance, we extract _basic_auth from the site dict exactly once and pass it into all five _http_status_check_stable() calls. Pulling it out from the dict at every call site invites "this one place forgot," so a local variable is the safer move.

UI — keep the rare case out of the way

From a user perspective, Basic-auth-protected sites are the minority. Putting two always-visible input fields in the site-add modal would clutter the UI for the 99% of sites that don't need them.

So we put the credentials behind a <details> element — a collapsed-by-default "🔐 Basic Auth (optional)" section at the end of the WordPress info group in the site-add/edit modal.

<details>
  <summary>🔐 Basic Auth (optional)</summary>
  <input name="basic_auth_user" placeholder="Auth username">
  <input type="password" name="basic_auth_password"
         placeholder="Auth password">
</details>

Users with Basic-auth-protected sites expand and fill it in; the rest see no change. Saved passwords go through Fernet with the ENC: prefix.

Closing — patterns for "same credentials, multiple paths"

Three principles worth keeping from this round:

When multiple paths need the same credentials, consolidate extraction into one helper. Playwright form, urllib form, boolean check — each consumer wants a different shape, but they should all derive from a single (user, password) root function. That keeps format drift from happening
For new fields on existing data, lean on empty-fallback patterns. site.get(key) or '' treats missing keys as "feature off," letting you add functionality without touching existing data. No migration needed
Hide rare features behind disclosure widgets. A field used by 1% of sites doesn't deserve top-billing visual space. A <details> collapse with a small icon expresses "optional feature" cleanly, and gets out of the way for everyone else

Staging environments behind Basic auth aren't rare in the WordPress world. If your automation tool is "half working" against those sites, teams quickly fall back to manual maintenance just for that subset. Designing a clean credential path through both the Playwright and urllib sides — once — is worth the up-front investment.

When paramiko's defaults silently get your IP banned — the look_for_keys and allow_agent trap

Susumu Takahashi — Tue, 30 Jun 2026 00:23:38 +0000

One day a multi-site administrator reported a strange bug: "After running the app's SSH connection test 2-3 times, my IP can't reach SSH on that server for a long while." The errors came back as Connection refused or Connection closed by .... The server wasn't down, and SSH from a different IP worked fine. The source IP was being temporarily banned at the server.

Two external investigation reports gave the cause: server-side protection mechanisms (fail2ban or PerSourcePenalties in OpenSSH 25+) detect short-windowed authentication failure spikes and temporarily ban the source IP. But the user had only clicked the test button 2-3 times — why were failures "spiking"?

The answer turned out to be paramiko's default behavior.

paramiko's default — trying many keys per connection

paramiko.SSHClient.connect() defaults two options to True:

client.connect(
    'host',
    pkey=my_key,
    # The following are True by default:
    # look_for_keys=True,   # also try ~/.ssh/id_* files
    # allow_agent=True,     # also try ssh-agent registered keys
)

When the explicitly passed pkey fails, paramiko falls back through ssh-agent registered keys → ~/.ssh/id_* files → password auth in order. Convenient for developers with a single key. Disastrous for a multi-site administrator:

The SSH agent has multiple per-site keys registered
~/.ssh/ holds several id_rsa / id_ed25519 files
A single connect call ends up trying 5-10 keys in sequence
That blows past the server's MaxAuthTries (default 6) on a single connection

So what looked to the user like "one connection test" was being seen by the server as "a suspicious IP racking up 5-10 auth failures in a row." Repeat that 2-3 times and the protection mechanism declares the IP "exceeded threshold" and bans it.

The fix — `look_for_keys=False` and `allow_agent=False`

paramiko exposes options to scope key trial. We set them explicitly in connect_kwargs:

connect_kwargs = {
    'pkey': my_key,
    'look_for_keys': False,   # don't try ~/.ssh/id_*
    'allow_agent': False,     # don't try ssh-agent keys
}
client.connect('host', **connect_kwargs)

Now "the explicitly passed pkey and nothing else" gets tried — failure ends in one attempt per connection. The MaxAuthTries-overrun path is gone.

Backward compatibility is preserved. Existing pkey / key_filename users see no change, and password-auth users are unaffected.

Lesson from V12: fix the same bug in 10 places at once

This is where the principle from the csh / bash-syntax SSH command bug paid off: the moment you find this kind of bug, grep for the same pattern everywhere. A full sweep of Connection(...) calls found 10 sites with missing or empty connect_kwargs:

Location	Role
`core/ssh_utils.py::get_ssh_connection`	Maintenance main path
`save_server_profile` WP-CLI auto-detect	Profile save
`test_ssh_profile`	Connection test
`discover_server_paths`	Path discovery
`test_wpcli`	WP-CLI test
`install_wpcli`	WP-CLI install
`diagnose_server`	Server diagnosis
`fetch_plugins`	Plugin list fetch
`fetch_pending_plugins_for_site`	Pending plugin fetch
`save_site` WP-CLI auto-detect	Site save

All 10 got a comment explaining the IP-block prevention rationale. If we'd patched only one, the same bug would have come back through a different code path.

We also removed a warning UI — automatic retries made it worse

In an earlier round we'd actually tried a different approach: diagnose private-key permissions before the connection test → show a warning + "Fix and connect" button. Well intentioned, but in this exact scenario it backfired completely.

The user-experienced sequence was:

Warning: "Your SSH key permissions are loose. Want to fix them?"
User clicks "Fix and connect" → internal chmod 600 → connection test auto-retries
Retry hits the same multi-key trial → fails
"Authentication failed" → try another key → fail again
Failures spike → IP ban triggers

"Warn the user, auto-fix, auto-retry" turns out to be a UX pattern that amplifies failure counts when the root cause lies elsewhere. The auto-retry hides multiple attempts behind a single user click.

Worse, paramiko doesn't enforce OpenSSH's StrictModes check, so for this app's purposes the key works fine even with loose permissions. The "helpful" preventive warning was actually overreach in our specific context.

We removed the warning UI in the same round (-120 / +31 = net 89 lines deleted). The _diagnoseAndOfferFix() function shell is kept for backward-compatible signatures, but its body is now a no-op.

Regression defense — an AST test that forbids empty `connect_kwargs`

Same two-layer defense pattern as V12: a regression test that fails the build if the bug ever comes back. tests/test_ssh_connection_isolation.py ships with 6 tests:

# Sketch
import ast

def test_all_connect_kwargs_have_look_for_keys_false():
    """Verify that every connect_kwargs / ck initialization
       contains 'look_for_keys': False and 'allow_agent': False."""
    for file in [CORE_SSH_UTILS, SITE_MANAGER_WEB]:
        for assign in find_connect_kwargs_assignments(file):
            keys = extract_dict_keys(assign.value)
            assert keys.get('look_for_keys') is False, \
                f"{file}:{assign.lineno} missing look_for_keys=False"
            assert keys.get('allow_agent') is False, \
                f"{file}:{assign.lineno} missing allow_agent=False"

If someone later adds a new SSH API and leaves connect_kwargs = {}, the build fails. Reading assign.value directly from the AST keeps comment / docstring strings from causing false positives.

Closing — three principles

Library defaults aren't always "correct" for your environment. paramiko's look_for_keys=True / allow_agent=True is reasonable fallback behavior for single-key users, but dangerous in multi-key environments. Re-read library docs through the lens of your actual deployment environment before trusting defaults
Warning UI + auto-retry can amplify the problem. "Warn the user, auto-fix, auto-retry" is well-intentioned but when the root cause lies somewhere else, the auto-retry compounds the failure count. UX-layer "helpfulness" can become operational debt
Find a same-shaped bug? Grep + AST regression test on the spot. Third entry in this pattern. The /bin/sh -c wrap / _safe_run helper (V12) and now the connect_kwargs scoping share the same shape: a fix needs to apply across every SSH path in the codebase. Cross-grep + AST regression test as a standard step changes how confident you can be about "did we get them all?"

SSH-related code tends to be exactly where "library defaults break under our environment" and "the same pattern scatters across many call sites" collide. If you're building a multi-site administrator tool on top of paramiko, defaulting look_for_keys and allow_agent to False from the start is the safer bet — that's what this round taught us.

DEV Community: Susumu Takahashi

The day a user told me "the running site looks weak" — rebuilding the three-state visual hierarchy with background color

At a glance, "running" looked weaker than "pending"

Express the hierarchy through background alpha

The second report — "the 24h green border doesn't show up"

Fix: "mark complete only on forward moves"

Reflection — don't treat "design oscillation" as failure

Lessons — verify visual hierarchy with alpha values

Visualizing maintenance status on the site list — blue pulsing border for running, green solid for done

Color picking — "red flashing" was the first thing we ruled out

Zero backend changes — reuse the existing log stream

On site switch, mark the previous one done

Auto-expire the done mark after 24h

Closing — "build the minimum, let production shake it"

Three pitfalls in a dashboard cache lifetime — boot-time restore, TTL, and partial invalidation

Pitfall 1 — All badges disappear on refresh

Lesson 1 — Tie cache restoration to the app's lifecycle, not its consumer

Pitfall 2 — A 7-day TTL was too short

Lesson 2 — Pair longer TTLs with explicit freshness

Pitfall 3 — One site's maintenance wiped every badge

Lesson 3 — Always scope state-clears to the execution

Closing — cache-lifetime design comes down to "your reader's lifecycle" and "your clear's scope"

A pending-plugin-count badge on the 🔌 button — reusing the dashboard cache instead of doubling state

Reuse the dashboard cache as the data source

Attaching the badge — consolidate into helpers

Thresholds that cut noise

Per-site checks update the badge too

Lessons — "if existing state answers it, don't add more"

A "days since last maintenance" badge — color-coding staleness across many sites

Why a date alone isn't enough

Four-tier color coding

Consolidate into helper functions

Safari-compatible date normalization

Future-date clamping (clock-skew defense)

i18n fallback

Lock the color thresholds with regression tests

Closing — "relative quantity + risk" beats "absolute value"

Detecting the running site from streaming logs — why log-order inference broke, and how one marker fixed it

The first design — "site switched, so mark the previous one done"

Bug 1 — log "rewind" marks an unstarted site as done

Fix 1 — reject rewind with an execution-order index

Bug 2 — the real root cause was the init loop's pre-emitted logs

Fix 2 — the marker approach (narrow to one line type)

Bug 3 — the completion reset was too aggressive

Lessons — inferring state from streaming logs

Quieting PHP 8.2+ deprecated noise from older WP-CLI — three layers to keep JSON parse clean

What was happening — Deprecated warnings on stdout

Why diagnostics stayed green but operations failed

Three layers of defense

Layer 1 — WP_CLI_PHP_ARGS to silence warnings at the source

Layer 2 — strip noise lines before JSON parse

Layer 3 — try JSON even when exit code is nonzero

Spread the fix across all three APIs at once

Closing — "warning-level differences × structured output"

Implementing a dynamic OGP image generator for our blog — PHP GD, per-post 1200 630 cards

The structural cause — "no featured image → LP default"

Two options — manual artwork vs dynamic generation

The core — ogp-generator.php (PHP GD, ~375 lines)

Japanese titles need a second font — Inter + Noto Sans JP

The functions.php patch — +28 / -2

Design decisions and the result

Closing — four principles for dynamic OGP

Diff from the live server, not from your git history — when a local repo has drifted from production

How this regression silently slips in

Two-stage rollforward — make production the source of truth first

Use MD5 to prove byte-for-byte preservation

Closing — "my git history is canonical" is a dangerous assumption

Multilingual emails from a Stripe webhook — inferring language from currency

Where do you get "the user's language" from? — three options

Implementing lang_from_currency

Pulling currency from the four webhook events

The subject-encoding trap — mb_language('uni' or 'Japanese')

The win of a no-DB-migration design

Closing — three patterns for webhook i18n

Maintaining WordPress sites behind HTTP Basic auth — Playwright, urllib, and encrypted credentials

What was breaking — two parallel paths, both blocked

The design — consolidate credential extraction into one helper

Backward compatibility — existing sites don't have these fields

Wiring both paths

UI — keep the rare case out of the way

Layer 1 — `WP_CLI_PHP_ARGS` to silence warnings at the source

The core — `ogp-generator.php` (PHP GD, ~375 lines)

The `functions.php` patch — `+28 / -2`

Implementing `lang_from_currency`

Pulling `currency` from the four webhook events

The subject-encoding trap — `mb_language('uni' or 'Japanese')`

The fix — `look_for_keys=False` and `allow_agent=False`

Regression defense — an AST test that forbids empty `connect_kwargs`