Aren't plugins required to default to update from wordpress.org if they're hosted on there?

[adegans]

That, the title - Are plugins required to default to update from wordpress.org if they're hosted on there?

How does Troy conflict with that?

When I wanted to switch from doing updates through wordpress.org to my own server a couple of years ago they were quick to point out, through email, that updates from anything other than wordpress.org must be opt-in by the user.
Nor can plugins ping other servers to "phone home" without the users explicit consent and opt-in. That would apply to update checks too, me thinks.

It would seem, to me anyway, that Troy and similar solutions loose their convenience quite a bit then if people need to consciously configure where their updates come from.
Especially since Troy and such are such novel systems that very few plugins use it - at least for now/the coming few years.

And then, if you don't host on wordpress.org - How would people find your plugin since so many people default to it. As an example, I know of several alternative repos/sources and rarely think to search on them.
Yes yes, seo and search... But really, practically, that's not an option for independent/small/low-budget devs. Discoverability through wordpress.org is kinda relevant.

[sybrew]

Hi Arnan, thanks for the questions! These are things I should clarify better in the docs.

The "opt-in" requirement

You're right that WordPress.org requires user opt-in for updates from external servers. Troy respects this, but the opt-in happens through trust in the plugin author.

Here's the flow:

1. Plugin author adds a Troy: header — This is just a comment in the plugin file (e.g., Troy: repo.example.com). It's not executable code. It tells Troy Client where to look for updates.
2. Plugin author creates a Package — Troy Server bundles the plugin with Troy Client into a single installer plugin ZIP. The author distributes this from their own site.
3. User installs the author's package — By downloading and installing the author's package, the user is trusting that author. Troy Client comes along with it. That trust IS the opt-in, though the author should state they're bundling Troy Client with the package (hard-coded in the installer); they can keep it simple and put the privacy note in the package description.

So the consent chain is: Author opts in via header → Author bundles package → User trusts author's package. The user's decision to install from the author (rather than WordPress.org) is the explicit consent.

The individual plugins don't need to "phone home." Troy Client does, and only for plugins with Troy: headers. Users who install plugins from WordPress.org without Troy Client are completely unaffected.

We put the power with plugin authors because users often don't know (or care about) the technical details of where updates come from. They trust the plugin author. If an author chooses the Troy distribution, that's part of trusting that author, just as it is to trust them not to ship malware.

Privacy note: Troy Client communicates with my server (repo.deploytroy.org) for its own updates, and with individual plugin repositories for their updates. No personal information is shared with me or any repository operator. None of your plugin's data is sent to me or other Troy repositories. Privacy by design—I cannot identify my users (no domain names or anything identifying is shared), and I can't see what plugins you have installed, other than the ones I'm serving via my repositories.

WordPress.org compatibility

Troy doesn't conflict with hosting on WordPress.org. You can do both:

• Host your plugin on WordPress.org for discoverability
• Add a Troy: header to serve updates from your own server
• Users with Troy Client get updates from you; users without get updates from WordPress.org

It's an additional distribution channel, not a replacement.

I've already done this for some of my plugins, and I've seen a few others do the same!

Discoverability

You raise a fair point about discoverability. A few thoughts:

1. WordPress.org search is already broken for small devs. The ranking algorithm favors install counts, creating a snowball effect where popular plugins stay popular, and new plugins remain invisible. Unfortunately, in this absurd status quo, marketing matters far more than being listed.

   However, I understand that it's much easier to tell users to "install it via plugin search" than to explain how to upload a ZIP. I have several plans for easing this friction, but I have nothing concrete to share yet. I'm still in draft mode on this front.

2. Troy doesn't solve discoverability—it solves independence. The point is to ensure you control your update pipeline, not to replace WordPress.org's directory.

3. Packages help distribution. Troy Server can bundle Troy Client with your plugin in a single ZIP. Users install your plugin, Troy Client is automatically installed, and future updates flow through your server—no extra steps.

4. Discoverability is on the roadmap. I've highlighted it as one of the problems, and I have drafts for a public plugin browser. More on that once I have something solid to share. This must be done right to respect user privacy and developer control.

For now, the practical answer is: use WordPress.org to help new users find your plugin, and use Troy to keep control of your audience when things go sideways.

For example, I bundle Troy Client with my self-hosted "Extension Manager" plugin. New users discover The SEO Framework on WordPress.org. If they later want extensions, they install Extension Manager from my site—which includes Troy Client. From that point on, The SEO Framework, which has the Troy: repo.theseoframework.com header, updates via repo.theseoframework.com instead of WordPress.org. If WordPress.org ever decides to remove my plugins, my paying customers are still with me. That's the core value proposition of Troy.

---

By the way, I read your recent post on what it would take to come back to WordPress. I feel that frustration deeply. Funny enough, Troy Server's plugin management is built entirely in Gutenberg—I wanted to prove I understand its pain points firsthand. It's genuinely awful to develop for, but I figured if I'm going to criticize it, I should at least demonstrate I've done the work. 😅

Let me know if you have more questions!

[adegans]

Yes, if the troy plugin is a deliberate install, then opt-in is assumed.
How does it handle if you have 2 plugins from different devs, both going through your system?
The one Troy client will know what to do?

Currently I actively "support" hub2wp, which grabs stuff from Github, skipping wordpress.org. It doesn't really solve the independency thing, rather moves the dependency to Github. But the practical use is similar to Troy. Lower effort to get into though...

For my own premium plugins I've developed my own distribution API/system, I simply bundle that with the plugin as a PHP file to be loaded, that reroutes update checks to my server. Also zero effort for the user. Those are not installed from wordpress.org either. Still, as an example, for Troy perhaps the update code should be part of the plugin in a similar fashion.

Then the plugin maker could include a switch to use either service. I think Automattic demands it defaults to them. But it's a start to make things easier. And the incentive for people to switch could be that updates from YOUR server will be released a few days early. Just a thought.

---

Thanks for reading my blog :)

[sybrew]

How does it handle if you have 2 plugins from different devs, both going through your system? The one Troy client will know what to do?

Yes and yes. Troy Client looks for the Troy: header in every plugin. If it's there, it'll filter the plugin out of requests to WordPress.org and redirect them to the URL specified by the plugin author. For example, all plugins with the header Troy: repo.example.com will request updates at https://repo.example.com/plugin/get/updates/ (in one go). Every unique Troy-repo URL registered makes a separate call.

But the practical use is similar to Troy. Lower effort to get into though...

I don't know if that's true. I can add a plugin to Troy within 20 seconds:

1. Set plugin slug. Troy Server will automatically repack ZIPs accordingly.
2. Set GitHub or WordPress.org integration (yes, Troy Server can fetch from WordPress.org).
3. Save. Done!

Troy automatically fetches new tags from GitHub or WordPress.org. There's no special configuration required.

You can dress it up if you'd like; that can take a few minutes per plugin (uploading images, assigning the author, etc.). But it builds everything required already from the plugin ZIP files.

Still, as an example, for Troy perhaps the update code should be part of the plugin in a similar fashion.

You only need the Troy Client. It handles everything: updates, caching, multisite support, etc.

Adding the updating logic inside a plugin creates issues. For example, can your plugins update when they're deactivated? Or will WordPress try to fetch updates for them from WordPress.org instead? Troy Client solves this by acting as an independent updater with a special lock: it cannot be deactivated if Troy-dependent plugins are installed; active or not.

And the incentive for people to switch could be that updates from YOUR server will be released a few days early

The incentive isn't with the user, but the developer. It's your code; you decide how people can get it. No gatekeepers. There's no need to persuade your users on this; they often don't know or don't care about the updating logic, as long as it works as-is. If they genuinely want your plugin, they'll get it and keep it.

[adegans]

Well this certainly sparks some ideas for what I use for updates for my paid plugins. And I think Troy is very interesting for various reasons, especially the independence idea.

One last thing though - Since I have a bunch of plugins on there but would like to do updates from my server 🙃
If Troy stops talking to WordPress for updates but the plugin is ALSO hosted on wordress.org, how do you keep your usage numbers up?
With that I mean the 200000+ users indicator for your SEO plugin for example. And by extension the version fragmentation graph on the Advanced tab on wp.org.

From my understanding if you don't send update requests, the repo won't know the plugin is there, so the usage numbers drop, making it look like no-one uses the plugin if they look at the plugin page there. How does troy handle that?

[sybrew]

You're correct. Usage numbers for your plugins on WordPress.org will decline.

However, since WordPress.org only shows the most significant number, I doubt anyone will notice.

In return, you get actual useful data from those "missing" users, like how many deactivated the plugin after installation.
You'll also find that it's pretty safe to support only the latest two versions of WordPress, because users who update your plugins also tend to update WordPress—although your graphs might tell you a different story.

I reckon that the data on WordPress.org/about/stats/ is misleading, for it includes too many abandoned sites. Yet, we're told to use it as a guideline. We cannot keep developing blindly; we've wasted too many hours.

[adegans]

Yep, I never really trusted the stats for plugins either.
In the sense that if they say a plugin has 20000 users, and then 7000-8000 people download it in the first 2 days after an update, which according to them represents ~10% of users... As happens time and time again with my AdRotate plugin for example. Am I not missing some 60000 users then? That would mean the 20k number is way way waaaay to low. As a result I rarely look at those stats anymore.

Gathering my own stats would be more useful.

But the usage number is useful for the uninformed user... More = better for them.

Anyway, when I have time I'll give Troy a go for my wp hosted plugins - Maybe I don't have to re-invent my own thing then.

Maybe at some point I (or someone) should figure out a way do the update check with .org, but ignore the response, then the numbers would be more in the devs favor 🥳

[sybrew]

Dripping plugin update requests to WordPress.org may cause the update to be rerouted/hijacked when Troy Servers are unreachable.

This is because the update_plugins site transient callbacks may be broken via another plugin, resulting in WordPress.org update responses overriding the author's intent. This issue occurs quite often due to caching plugins.

I have deliberately filtered Troy-enabled plugins (and coming soon: themes) from reaching WordPress.org via Troy Client to prevent this issue. I'm also considering filtering Troy-enabled plugins from other repos, such as FAIR or ClassicPress, ensuring updates always come from the developer's Troy Server, while still allowing the other repos to provide updates for other plugins and themes.