[wp-trac] [WordPress Trac] #62132: Make wordpress.org API connections for updates, plugins and themes configurable to a different location

WordPress Trac noreply at wordpress.org
Mon Aug 25 15:18:17 UTC 2025


#62132: Make wordpress.org API connections for updates, plugins and themes
configurable to a different location
--------------------------------------+------------------------------
 Reporter:  jamesking56               |       Owner:  (none)
     Type:  feature request           |      Status:  reopened
 Priority:  normal                    |   Milestone:  Awaiting Review
Component:  Upgrade/Install           |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+------------------------------

Comment (by desmith):

 So, tbh I haven't thought too much about this ticket in a while, because
 the [https://github.com/fairpm FAIR] plugin seems to cover (most of?) the
 use cases for this core patch, and was written by a number of Very Smart
 People (which I am not).

 Hosts that want to use FAIR on their customers' sites can pre-install it,
 and set up its configuration (mainly its `FAIR_DEFAULT_REPO_DOMAIN` env
 var, I imagine), as part of their site provisioning process. Individuals
 setting up their own sites, who are interested in using a non-.org site
 for plugins, can install FAIR on their own easily enough too. (It'd be
 nice if FAIR itself were available on .org so things like wp-cli could
 install it without needing to jump through an extra hoop, but that's a bit
 outside the scope of a trac ticket.)

 All that said, at a glance it looks like FAIR ultimately "just" uses the
 same sort of `pre_http_request` filter logic as @jorbin's original
 suggestion from months ago. Would there be any meaningful benefit to
 implementing a patch like this anyway? I suspect there would be a small
 performance benefit, since that filter presumably has to inspect every
 HTTP request, and this patch would save those calls, but I'm not sure the
 juice is worth the squeeze.

 (The patch is still where I left it, last I recall I couldn't get the non-
 standard API endpoint health check to work correctly. If anyone wishes to
 pick this up and see what I'm overlooking there, I'd appreciate the help.)

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/62132#comment:25>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list