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 doesn’t have an expiration date attached to it. The code does, though, and the gap between those two facts is where the work lives.
Eleven years later: easy-popular-posts and easy-recent-posts
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; the active-install band is a range; neither 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 — services that no longer exist, hard-coded URLs pointing nowhere. Class names were inconsistent across files. The localization sat in a langs/ directory using the 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 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 is: 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.
WPShadow is now This Is My URL Shadow
The diagnostics plugin — 230+ automated checks across performance, security, SEO, and accessibility — was shipping under the name WPShadow. It’s now This Is My URL Shadow.
This isn’t a marketing move. It’s a clarity decision. If a plugin is going on client sites and going 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; the name should carry the same accountability the code does.
The thing worth writing down is: when a plugin’s name doesn’t identify its author, the author has quietly opted out of the responsibility. The rename closes that gap.
Also this week
thisismyurl-svg-support 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. The Canadian WordPress community deserves a plugin that speaks their language while it does that job.
sitekit-portal-pin isn’t legacy — it’s a newer plugin — but the 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 CI is flaky, eventually something ships that shouldn’t have, or doesn’t ship that should have. Keeping it clean is part of taking the work seriously.
What you owe
Publishing to WordPress.org isn’t publishing into a void. It’s publishing into a community that has 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.
And then there’s the simpler obligation. Somewhere right now, somebody is installing a plugin I wrote in 2015 onto a site they care about. They don’t know me. They trust the directory, which means they’re trusting whoever’s name is in the header. The code they get this week is dramatically better than the code they would have got last week. That’s not a feature. That’s the floor — and it should have been the floor the whole time.
The name on the plugin is the same name on this site. The code should reflect who I am now, not who I was when I wrote it.
Last Reviewed
This article was last reviewed on May 11, 2026 for accuracy and relevance.
