No More Accidental Custom Plugin Overrides, WordPress 5.8 To Allow Developers To Set Plugin Hostname

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.

9 responses to “No More Accidental Custom Plugin Overrides, WordPress 5.8 To Allow Developers To Set Plugin Hostname”

  1. Nice feature.

    I had someone having installed one of my plugins encounter this issue a month ago after a third party released a similar plugin, with the same naming for the main file, to the WordPress directory.

  2. Thanks for writing about this.

    One thing however: Rule #8. “Plugins may not send executable code via third-party systems.” is — as my dad would say — clear as mud.

    Maybe you could write a follow-up post that explains what this means, in lieu of them actually editing the rules so that Rule #8 would be clear enough to understand? Thanks in advance if you do.

    • Yeah, I was thinking the same thing reading #8. I figured most readers would be in the same boat, so I quoted the sub-section of that guideline that more clearly explained what was not allowed for this situation.

  3. Where will this new header go in the case of themes? The style.css file or the readme.txt file?

  4. Will this rescue info from things that were kicked out of the .org ecosystem like wp-spamshield?

    perhaps offer a one click duckduck search for info that may be posted on the web about plugins not updated via .org in X many months or something?

    that might be helpful.

    I have some plugins on some sites that have not been updated in years – yet I have not found the functionality available in newer plugins – plus I have a half dozen here and there from ‘premium’ places around that I have not updated and don’t know if there are updates and no way to gain support – or to know if there are exploits in them or new ones avail..

    Will this method also be able to alert about url changes / ownership changes of plugins eg-> https://wptavern.com/should-wordpress-notify-users-of-plugin-ownership-changes
    ?

    Cool possibilities I guess.

    • This will only work if plugin authors opt into the new Update URI field. If they don’t, it’ll be the same as before. The new piece is that the solution is there and takes one line of text in the primary plugin file.

      So, something like the spam plugin you mentioned could add the header to avoid checks from WordPress.org. You could do the same for non-.ORG plugins.

      As for URL and ownership changes, no. Those are separate things. This new feature basically tells WordPress the hostname to check for updates.

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: