Almost since the dawn of including plugin and theme upgrade mechanisms in the kernel over a decade ago, third-party developers have been asking for an easy way around the system. WordPress 5.8 will finally meet this demand for functionality.
Although it has long been possible to filter the update system, the methods of doing so were more complex than necessary. They also required that the plugin itself be active on a site. A simple flag to enable / disable the feature on a per plugin basis is long overdue.
“The utility is that this is an abstract API that does two things,” Dion Hulse wrote in a GitHub fetch request that fixed the code:
- A plugin for declaring a URI / string which, if set, the WordPress.org update APIs ignore the plugin.
- Code running on the site can use these hostname / data headers to offer a plugin update to be stored in the update transient, without having to jump through obstacles such as replacing the transient / check too often / etc.
WordPress 5.8 will have a new Update URI plugin header field. If its value is anything other than https://wordpress.org/plugins/{$slug}/ or w.org/plugin/{$slug}, WordPress will not try to update it.
Beyond that, developers can deploy their own solutions if they want to handle updates to non-WordPress.org plugins. This is where the new update_plugins_{$hostname} the filter comes into play. WordPress will analyze the URL included in the plugin Update URI header and use the hostname as the value. Developers can then log in and do whatever they need.
Authors of plugins with plugins hosted by WordPress.org won’t have to worry about adding this new header. Rule # 8 of the Plugin Guidelines already prohibits sending executable code through third-party systems. The following subsection more specifically covers this scenario:
Serve updates or install plugins, themes or add-ons from servers other than WordPress.org
The discussion gained momentum 13 months ago on a six-year post. “A plugin has now been unceremoniously removed from a customer’s website while performing the plugin’s automatic update,” wrote a contributor with the username. apedog. “This is actually the second time that I have encountered this name conflict issue for one of my plugins. In both cases, I had chosen a plugin name without a prior naming conflict. However, later someone else had also written a plugin with the same generic name and submitted it to the wp.org repository. From there, the proper functioning of my plugin is interrupted.
While the deletion issue didn’t turn out to be a problem on the WordPress side, perhaps it was the spark needed to keep the conversation going.
An active chat doesn’t always indicate that a feature is getting the green light. It also doesn’t mean that someone will write the code. Many of these posts had months or years of conversation, only to languish and die. This ticket also seemed to match this bill. It was opened in 2015. However, sometimes new features are more a matter of timing, just pure luck, or a developer with master commit access just doing the job.
The ticket for the plugins has been accepted and committed on WordPress. However, there remains the question of whether this will land for the themes. The movement in the 11-year-old themed post indicates it could happen.
