Almost since the dawn of the plugin and theme upgrade mechanisms inclusion in core over a decade ago, third-party developers have asked for an easy way to bypass the system. WordPress 5.8 will finally deliver on this feature request.

While it has long been possible to filter the update system, methods for doing so were more complex than needed. They also required the plugin itself to be active on a site. A simple flag for enabling/disabling the feature on a per-plugin basis is long overdue.

“The utility is that this is an abstracted API that allows two things,” wrote Dion Hulse in a GitHub pull request that patched the code:

• A plugin to declare a URI/string that if set, WordPress.org update API’s ignores the plugin.
• Code running on the site, can use that headers hostname/data to offer an update for the plugin to be stored into the update transient, without having to jump through hoops such as overriding the transient / checking too often / etc.

WordPress 5.8 will have a new Update URI plugin header field. If its value matches anything other than https://wordpress.org/plugins/{$slug}/ or w.org/plugin/{$slug}, WordPress will not attempt to update it.

Beyond that, developers can roll their own solutions if they want to handle updates for non-WordPress.org plugins. That is where the new update_plugins_{$hostname} filter comes into play. WordPress will parse the URL included in the plugin’s Update URI header and use the hostname as the value. Developers can then hook into it and do whatever they need.

Plugin authors with extensions hosted by WordPress.org will not need to worry about adding this new header. Rule #8 of the plugin guidelines already disallows sending executable code via third-party systems. The following sub-section covers this scenario more specifically:

Serving updates or otherwise installing plugins, themes, or add-ons from servers other than WordPress.org’s

The discussion picked up some steam 13 months ago on a six-year-old ticket. “I’ve now had a plugin unceremoniously deleted from a client’s website when scheduled plugin automatic-update have run,” wrote a contributor with the username apedog. “This is actually the second time I’ve encountered this naming-conflict problem for a plugin of mine. In both cases, I had chosen a plugin name with no apriori naming conflict. However, at some later point, someone else had also written a plugin with the same generic name and submitted that to the wp.org repository. From that point on my plugin’s proper functioning is broken.”

While the deletion issue turned out not to be an issue on WordPress’s end, perhaps it was the spark needed to keep the conversation going.

An active discussion is not always indicative of a feature getting the green light. Nor does it mean someone will write the code. Many such tickets have had months or years of conversation, only to eventually languish and die. This ticket seemed to have fit that bill too. It was opened in 2015. However, new features are sometimes more about timing, just pure randomness, or a developer with core commit access simply getting the job done.

The ticket for plugins has been accepted and committed to WordPress. However, there is still the question of whether this will land for themes. The movement in the 11-year-old theme ticket indicates that it could happen.