The code wasn’t broken when you went back. The code was working. What you went back to fix wasn’t the code; it was a contract you’d forgotten you’d made.
Your name on a plugin in the WordPress.org directory is a standing commitment. Not updating it isn’t the same as retiring it. As long as the listing is live, that code is installing on new sites, sites belonging to people who trusted the directory and, by extension, trusted whoever shipped the thing. That trust comes with no expiration date attached to it. The code does, though, and the gap between those two facts is where the work lives.
I spent last week giving editorial opinions their own schema. This week I went the other direction, back into code I shipped before some of the people now installing it had heard of WordPress, and asked a question I had been avoiding for eleven years.
Bringing eleven-year-old plugins back to a quality floor
I last touched Easy Popular Posts and Easy Recent Posts on WordPress.org in January 2015. The SVN history is unambiguous: v15.01.12 and v15.01, last revision by christopherross. Both plugins have been quietly installing on new sites that whole time. I have no way to know how many. The download counter is a number, and the active-install band is a range, and neither one tells me anything about whose site is running 2015-era code with my name in the header.
This week I imported both plugins from the WP.org SVN into GitHub and did a full rewrite. Thirty-nine bug fixes each. The list is unglamorous in exactly the way old code is unglamorous. The shortcode was echoing instead of returning, which meant any theme that tried to assign it to a variable got output-buffering surprises. There were dead social-sharing links baked into the markup, pointing at services that no longer exist, hard-coded URLs that go nowhere. Class names were inconsistent across files. The localization sat in a langs/ directory using a pattern that predates load_plugin_textdomain as we know it now.
None of that was acceptable in 2015 either. I just didn’t go back and fix it. The PHPCS blockers are gone now. Both plugins meet WordPress Coding Standards. Both ship with fr_CA translations, because I live in Canada and the people running my code in French Canada deserve a plugin that speaks to them in their own language.
What the plugins do hasn’t changed. They display popular and recent posts via widget and shortcode. No external APIs, no telemetry, no surprise dependencies. This wasn’t a feature rewrite. It was a quality floor, bringing eleven-year-old code up to the bar I’d hold any new release to today. The check I run is simple. If I shipped this fresh tomorrow under my current name, would I be comfortable with every file in it? The answer had to become yes before either plugin went back out.
Why a diagnostics plugin needs your name on it
The diagnostics plugin that runs 230+ automated checks across performance, security, SEO, and accessibility used to ship under the name WPShadow. It is now This Is My URL Shadow.
This isn’t a marketing move. It’s a clarity decision. If a plugin is going onto client sites and into the WordPress.org directory, the name should point unambiguously back to the person responsible for it. “WPShadow” could be anyone. “This Is My URL Shadow” tells you exactly whose work it is and where to find them when something needs fixing. The plugin runs against live sites, and the name should carry the same accountability the code does.
The thing worth writing down: when a plugin’s name doesn’t identify its author, the author has quietly opted out of the responsibility. The rename closes that gap. It is a small change in the readme and a large change in what I am willing to put my name behind.
Language and CI: the quieter parts of the same job
Two smaller pieces of work this week belong to the same obligation, even if neither makes for a headline. The first was thisismyurl-svg-support, which got its internationalization pass and a fr_CA translation. The security hardening story already went out in an earlier post, so I won’t rehash it here. The framing is the same as for the widget plugins, only sharper. A plugin that handles SVG uploads sits on top of one of WordPress’s longest-running attack surfaces, and the Canadian WordPress community deserves a plugin that speaks their language while it does that job.
The second was sitekit-portal-pin, which isn’t legacy. It’s a newer plugin, but its GitHub Actions wiki-initialization workflow needed corrections this week. Not interesting on its own. Worth mentioning only because the release pipeline is part of the same commitment. If the continuous-integration (CI) run is flaky, eventually something ships that shouldn’t have, or doesn’t ship that should have. Keeping that pipeline clean is part of taking the work seriously, in the same way that wiping down your tools in practice is part of the woodworking and not separate from it.
What you owe the people who never met you
Publishing to WordPress.org isn’t publishing into a void. It’s publishing into a community that holds collective standards: accessibility, security, coding conventions, internationalization, the rest of it. Those standards exist because thousands of people built them over two decades. Meeting them isn’t a hoop to jump through. It’s how you respect the people who made the place you’re shipping into. That is the part of this work I think about most, and it is the part I take to client engagements through my WordPress work as much as I take any line of code.
And then there’s the simpler obligation, the one with a face on it. Somewhere right now, this afternoon, someone is installing a plugin I wrote in 2015 onto a site they care about. Maybe it’s a small business, maybe it’s a community group, maybe it’s a person who just wants their recent posts in a sidebar. They don’t know me. They have never heard my name and have no reason to. They trust the directory, and trusting the directory means trusting whoever’s name sits in the plugin header. This week, that person gets code that is dramatically better than the code they would have gotten last week, and they will never know the difference. They shouldn’t have to. That is what I owe them, and it’s what I owed them the whole time I wasn’t looking.
Product names referenced on this page, including WordPress and GitHub, are trademarks or registered trademarks of their respective owners. Training offered here is independent and is not affiliated with, endorsed by, or sponsored by any of these companies.