Troubleshooting guide · website-errors · Published 2026-08-16 · 3 min read
PHP allow_url_fopen disabled breaks plugins and remote requests
How allow_url_fopen controls remote file reads, the errors it causes when disabled, and safe ways to fetch remote data.
- ·Symptoms
- ·Causes and impacts
- ·Safe fixes
Symptoms
A plugin stops updating, a theme import returns Failed to listen to that URL, or PHP writes a warning like PHP Warning: file_get_contents(): URL file-access is disabled in the server configuration to the error log. The site itself still loads, because the failure is confined to code that fetches data over HTTP. The error names the PHP directive allow_url_fopen.
What allow_url_fopen actually controls
allow_url_fopen is a php.ini directive that decides whether the PHP functions that open local files can also open network URLs. When it is On, a call like this works:
$result = file_get_contents('https://example.com/feed.xml');When it is Off (the value that many shared hosts ship for security hardening), the same call fails, often with the "URL file-access is disabled" warning. The functions it governs include file_get_contents(), file(), fopen() when the path starts with http:// or https://, and include()/require() only when allow_url_include is also on (which is almost always a separate, deliberately off setting).
The directive does not block cURL. It affects PHP stream wrappers, and the set of wrappers allowed is controlled by stream_wrapper_restrictions.
Typical broken pieces
| Feature | What breaks |
|---|---|
| Plugin or theme updater that verifies a remote endpoint | Update hangs or reports "download failed" |
| Importers pulling a remote image or RSS feed | Import shows nothing and logs a warning |
| Scheduled jobs that fetch JSON (heartbeat, sync) | Jobs skip the fetch and repeat on every run |
| License expiry checks | Feature gates report expired because the check cannot run |
An intermittent symptom matters too: code that catches the @file_get_contents() result fails quietly; only the success path was visible before, so the break appears as "this used to work but nothing changed".
Is it safe to re-enable?
Turning allow_url_fopen back On is the quick fix, but it is exactly what the host disabled it to prevent: PHP gaining access to arbitrary remote URLs from the same process that also has access to your database and config files when an attacker wins an injection point. The sensible order is:
- Check what the add-on needs. The vast majority of updaters and license checks can use cURL. Modern WordPress ships with
wp_remote_get(), which prefers cURL and does not depend onallow_url_fopen. - Ask the author for a cURL-compatible mode before you flip the directive for them.
- If the plugin truly requires URL file access, bind the change narrowly: set
allow_url_fopen=Ononly for the specific site via.user.ini(Apache/FPM installs) rather than globally, and read the PHPmysqli.allow_url_includevalue first. Keep it off when the vendor confirms cURL works.
Verifying the fix
After any change, confirm the directive value the way the running PHP actually sees it, from a file in the document root:
var_dump(ini_get('allow_url_fopen'));If you changed PHP-FPM, the web server must be reloaded before the value updates. Then retry the exact failing operation, then watch the error_log for the remote-line warning the next time it runs.
The plugin rollback article covers the recovery path when an updater fails before it writes anything, and error-log-reading walks the log lines that identify exactly which remote host and function failed.