WordPress shipped 7.0.2 as a security release, and the announcement used a word you do not see often: forced. As in, WordPress.org reached into affected sites and updated them whether or not anyone was watching, because the hole it closed did not need a login, a plugin, or any particular setup. It needed your URL. That is the kind of week that reminds you WordPress is a real thing a large slice of the web is standing on, and that the floor can move.
So the week had two halves. The loud problem everyone patched at once, and the quiet problems sitting on my own site that nobody had thought to look for.
A security release you did not get to schedule
The bug behind 7.0.2 was the bad kind. A pre-authentication path to running code on a default install, chaining a confused REST route with a SQL injection, no login required. When a fix like that ships, the clock does not start ticking, it is already late: the moment the patch is public, the difference between the old code and the new code is a map to the exploit, and someone rebuilds it within the day. WordPress forcing the auto-updates did most of the heavy lifting, which is the whole argument for auto-updates in one sentence.
The part left for me was the unglamorous one. The catch with a forced update is that it still has to land somewhere real, and plenty of sites give it a reason not to. A site can be on an old branch, or have auto-updates switched off by a well-meaning host, or be a staging copy someone forgot about. So the real work was going site by site through the ones I look after and checking that the update actually landed and nothing broke on the way in, rather than assuming the platform had it handled. Security is mostly confirmation, done on a boring afternoon, and the afternoons you skip it are the ones you remember.
The bug I filed against WordPress itself
In the same week WordPress was patching a serious one, I found a small one, in core. Two of the functions you lean on constantly, the ones that answer “is this a page” and “is this a single post,” quietly return the wrong answer when a permalink starts with a segment shaped like a domain name. Not a security hole, just a wrong-answer bug, the kind where a conditional lies to you with a straight face and the page renders as something it is not. I wrote a patch and filed it upstream on Trac. Filing a bug against the thing you build on every day is a strange kind of loyalty, but a working conditional is worth more than my pride in the software being flawless.
The glossary that was a wall with a door painted on it
Then a finding that stung, because it was mine to have caught long ago. My glossary is the single biggest source of search traffic to the site. People land on a definition of a term they half-know, from a search, all day long. And 99% of it went nowhere. Of a hundred and three terms, exactly one linked out to anything else on the site. The biggest front door in the building opened onto a painted wall, and every visitor who came through it turned around and left, which the numbers had been telling me for months in a language I had not bothered to read. I spent an afternoon connecting terms to the pages and posts that actually use them, so the door opens onto a room now.
The post that greeted readers with an error message
And the small humbling one. A published post whose literal first sentence, the thing a reader and a search engine both see first, was a line of command-line output. “Warning: Constant already defined,” or words to that effect: a stray bit of terminal noise that got captured into the draft when the post was created and then sat at the top of the page for months, greeting everyone like a doormat that reads GO AWAY. Nobody had mentioned it, which is the quiet-problem pattern in one example. I cut it, then went looking for siblings, because these things travel in families.
The through-line, if a week needs one: the security release was the loud kind of problem, the kind the whole ecosystem fixes in an afternoon because everyone can see it. The dead-end glossary and the error-message doormat are the quiet kind, the kind nobody reports because it is nobody’s job to, and the quiet kind is the one that actually costs you the reader. The one piece of unambiguous good news was Access 2026 in Hamilton saying yes to a talk on accessibility audits, which felt about right for a week spent finding the things nobody audits. If a second set of eyes on the quiet problems on your own site sounds useful, that is the audit I do. Last week’s notes, on the WordCamp US yes and a handful of machines that misled me, are in the previous Behind the Scenes.
Leave a Reply