A client a while back wanted to be on the “cutting edge.” They had found a feature plugin in the official WordPress organization on GitHub and insisted we use it on their production store. I went along with it, on the theory that anything living in the official org is basically core code. That theory was the mistake. We built a whole custom checkout flow on top of it, the repo went quiet for two years, and then it was archived.
This is what WordPress repository maintenance actually means in practice. The “WordPress” badge on a GitHub repo is not a promise that the code will suit a high-traffic production site forever. The project recently ran a “little late spring cleaning,” written up on the official Make blog, and archived about 20 repositories across the WordPress and bbPress organizations. Read that list as a statement of what is supported.
The lifecycle of an official feature plugin
The archived repositories tend to be one of a few things: feature plugins already merged into Core, like the original REST API or the Gutenberg experiments, projects that lost their internal champion, or ideas that did not pan out. Archiving makes a repo read-only, so it stops receiving security patches and bug fixes. Code you are still running from one of those repos has nobody behind it.
Developers pull code straight out of these “active” feature repos all the time, usually because they want something Core does not have yet. It feels like a head start and it is really an inherited maintenance bill. Treat a feature plugin as experimental until it either lands in the official plugin directory or gets merged. If you use one before then, plan on maintaining that code yourself the day the Core team moves on.
When I audit a site for WordPress repository maintenance, the first thing I hunt for is orphaned code: functions or hooks that only ever existed inside one of these archived projects. If a site leaned on an old feature plugin for metadata handling, for instance, that data probably needs bridging back to standard WP metadata structures now the experiment is over.
<?php
/**
* A simple sanity check to ensure we aren't relying on
* hooks from a known archived feature plugin.
*/
function bbioon_audit_legacy_features() {
// Example: Checking for a defunct hook from an archived experiment
if ( has_filter( 'old_experimental_feature_hook' ) ) {
error_log( 'BBIOON Alert: Site is using hooks from an archived repository.' );
}
}
add_action( 'admin_init', 'bbioon_audit_legacy_features' );
Knowing where your code came from
The cleanup is good for the community and uncomfortable for agency owners and lead developers, because it forces the question of where your code came from. A “custom solution” that turns out to be a wrapper around a five-year-old GitHub experiment is neither custom nor solid. I have rewritten entire modules because a “standard” feature plugin got archived and then stopped working with a newer PHP version.
This gets complicated fast. If you would rather not spend your week debugging someone else’s mess, drop my team a line. We have probably seen it before.
When did you last read through your composer.json or your plugin list looking for abandoned “official” projects?
