WordPress:  Disable external HTTP requests

detox1978
detox1978 used Ask the Experts™
on
Hi All,

I am trying to setup a WordPress site for a company that does not have internet access.  It takes quite a while to load as each of the external HTTP requests have to time out.

Is there a way to disable / block the HTTP requests?

I tried adding this to my wp-config.php, but it doesn't appear to have done anything.

define('WP_HTTP_BLOCK_EXTERNAL', true);

Open in new window



Any suggestions?
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Most Valuable Expert 2011
Top Expert 2016

Commented:
Why not remove the external HTTP requests?  Then you would not have to wait for them to time out.

Or better yet, get internet access.  It's literally pennies per day.  They could buy a year of internet access for the price of getting this question answered! ;-)
David FavorFractional CTO
Distinguished Expert 2018

Commented:
You're asking about DNS rather than WordPress. Yes WordPress has a facility to attempt this + never seems to work correctly.

Blocking all external requests will likely produce very odd site behavior, which can be maddening + time consuming to debug.

WP core + themes + plugins will all be continually out of date + hackable from inside your Intranet (internal network).

Likely all sorts of thing will work... oddly...

A much better way to fix this type of problem is to run your site through https://WebPageTest.org + just fix all the problems turned up. WPT will tell you exactly what you have to fix to speed up your site.

You can accomplish this several ways. Each way has it's complexity.

My suggestion understand what you're truly trying to accomplish. Likely something different than your question suggests.

Ways to truly isolate WordPress.

1) Hack the Requests Library, through which all WordPress requests funnel. Only allows requests to certain IP ranges within your Intranet.

This means any time you update WordPress core + the update overwrites this library + you'll have to rehack the related files.

Use the Linux patch program to automate this. Work with many small patchsets, rather than a single monolithic patchset will give you a better chance of patch working each time you apply all your patchsets.

If any APIs in the Requests library change or anything changes in how WordPress makes calls through the Requests library, you'll likely have to recode your solution.

2) Hack your DNS.

You'll have to arrange for all users inside your Intranet to use your Internal Hacked DNS servers, so you'd block all outgoing port 53 UDP + TCP connections, unless those connections are being forwarded from your Hacked DNS servers.

Then in your DNS servers you'll hack the config... which is going to be very hard.

For every external request, you'll spoof or force the request to 127.0.0.1 which will blackhole the request.

You'll then have to recode your theme + plugins to work correctly with this type of DNS setup, so anything which is normally external... like Google Fonts will have to be scraped from their external location + placed on a Webserver inside your Intranet + then all references in your theme + plugins changed to reference the IP or host of this Webserver.

3) Use the WP_HTTP_BLOCK_EXTERNAL with WP_ACCESSIBLE_HOSTS which will attempt to mimic #2 via WordPress.

I've never had much luck getting this to work.

To debug this approach, install XDebug + set xdebug.scream=1 in the xdebug.ini file + restart Apache.

Then set WP_DEBUG in your wp-config.php file + you'll likely see a variety of problems, which you'll have to debug one by one.

Note: While your doing any of this...

Also refer to your Apache access.log + error.log for any other problems to debug.

Turn of any useless tech like CDNs + NGINX/Varnish (anything that makes debugging difficult). Useless, because if you actually test your site speed with a tool like WPT you may find the primary speed problems are tech mentioned.

Also disable Opcache (by setting enable=0 in opcache.ini) else you'll have another layer to debug.

Also flush + disable any WordPress caching, else you'll have another layer to debug.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial