Opened 7 weeks ago
Last modified 9 days ago
#65395 new defect (bug)
Site Health falsely reports "Opcode cache is not enabled" on shared hosting (WP 7.0)
| Reported by: | kofwae | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | Awaiting Review |
| Component: | Site Health | Version: | 7.0 |
| Severity: | normal | Keywords: | has-patch has-unit-tests needs-testing |
| Cc: | Focuses: |
Description
Hello,
I am experiencing a false positive/negative warning in the Site Health tool under WordPress 7.0. The tool reports that "Opcode cache is not enabled".
However, checking the server's phpinfo() clearly shows that Zend OPcache is "Up and Running" (enabled on the server level by the hosting provider).
According to my hosting support (Blueboard.cz), on shared hosting environments, direct management/clearing of OPcache via PHP functions (like opcache_reset) is restricted for security and stability reasons to prevent users from affecting other tenants on the same server.
It seems that the Site Health tool in WP 7.0 flags OPcache as disabled simply because it lacks administrative privileges to control it, even though the caching mechanism is actively running and optimizing the site. Could the check be adjusted to only look for the extension status, rather than requiring full write/reset permissions?
Thank you!
Attachments (1)
Change History (10)
This ticket was mentioned in PR #12080 on WordPress/wordpress-develop by @yashyadav247.
6 weeks ago
#3
- Keywords has-patch has-unit-tests added
Fixes a false “Opcode cache is not enabled” Site Health warning on shared hosts where Zend OPcache is active but opcache_get_status() returns false because the host blocks OPcache API calls (commonly via opcache.restrict_api).
This behavior was introduced in WordPress 7.0 with the new opcode cache Site Health test (#63697).
Changes:
Add wp_opcache_is_enabled() in wp-admin/includes/file.php, alongside existing OPcache helpers. Uses opcache_get_status() when available; otherwise falls back to ini_get( 'opcache.enable' ) when the status API is unavailable.
Update WP_Site_Health::get_test_opcode_cache() to use the new helper.
Update WP_Debug_Data so restricted hosts show “Enabled (statistics unavailable due to server configuration)” instead of “Disabled by configuration”.
Add/update PHPUnit coverage in wpOpcacheIsEnabled.php and wpSiteHealth.php.
This ticket was mentioned in Slack in #core by yashyadav247. View the logs.
6 weeks ago
This ticket was mentioned in Slack in #core by abdullahramzan. View the logs.
6 weeks ago
@yusufmudagal commented on PR #12080:
6 weeks ago
#7
Tested the patch locally against current origin/trunk in a disposable worktree.
Results:
php -l src/wp-admin/includes/file.phppassed.php -l src/wp-admin/includes/class-wp-site-health.phppassed.php -l src/wp-admin/includes/class-wp-debug-data.phppassed.vendor/bin/phpunit --filter 'test_wp_opcache_is_enabled_returns_bool|test_wp_opcache_is_enabled_matches_environment'passed: 2 tests, 2 assertions.\n\nThe new OPcache helper coverage passes for me.
#8
@
13 days ago
I tested this on a local WordPress 7.0 installation with OPcache enabled through php.ini. After restarting the web server, phpinfo() confirmed that Zend OPcache was Up and Running, and WordPress Site Health correctly reported that Opcode cache is enabled. I was able to reproduce the reported behavior in my local environment. Based on my testing, this issue may be specific to certain shared hosting environments where OPcache management functions are restricted or unavailable.
#9
@
9 days ago
Tested the patch on a live production environment hosted on Blueboard.cz (a shared hosting provider that restricts the OPcache API / opcache_get_status() for security reasons).
Before the patch:
Site Health incorrectly reported "Opcode cache is not enabled", even though Zend OPcache was up and running on the server level.
After applying the patch:
The false negative warning immediately disappeared. Site Health now correctly flags OPcache as enabled, and the Info > Server tab displays the new text: "Enabled (statistics unavailable due to server configuration)".
The patch works flawlessly in a real-world restricted shared hosting environment.
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png)
Hi,
I'm also seeing the same issue on websites hosted on OVH's shared hosting.
The Site Health tool display the message: Opcode cache is not enabled and in the tab Info> Server, for Opcode cache: Disabled by configuration.
With phpinfo()
Thank you.