Add OPCache to Site Health

[oglekler]

Add OPCache to Site Health > Info > Server.

There is a lot of information about OPCache that can be viewed and possibly not all this information is needed at the first glance, but it will be good to have basic checks if OPCache and OPCache CLI are enabled with a link for further information.

[westonruter]

If opcache isn't enabled then this should also get flagged in a Site Health test too, right? So perhaps the scope here should be to add a test as well as to add the site health info.

[johnbillion]

I support this idea.

Pedantry: This should be an "Opcode cache" health check, OPcache is one implementation of a PHP opcode cache, although in reality all the other opcode cache engines such as APC and eAccelerator were discontinued a decade or more ago.

This PR adds OPCache information to the Site Health Info page so administrators can see how their PHP OPcache is performing.

The code checks if OPcache is available using extension_loaded('opcache'), then gets detailed status using opcache_get_status(). It displays both user-friendly formatted values and debug information for copying to clipboard. All text is properly internationalized and follows WordPress coding standards.

Trac ticket: https://core.trac.wordpress.org/ticket/63697

[rollybueno]

Since this is accepted to Future Release, I've submitted initial patch that can be extended as the ticket progresses.

First it will check for OPCache extension availability, then if loaded, it will use opcache_get_status() to get the following information: used_memory + free_memory = OPcache memory usage, opcache_hit_rate, num_cached_scripts and num_cached_keys. These can be updated once we decided what information we need to display here.

I take these keys from ​https://www.php.net/manual/en/function.opcache-get-status.php response, but I have not fully tested yet. Only this information is available so far, in my end:

If using extension_loaded('opcache'), the result is always false even if it's set to 1. The only time it works is if I use extension_loaded('Zend OPcache'). It's giving mixed results so I'm not sure which one should be more reliable as this could go down per hosting choices.

The question is, should we do a more robust approach by using function_exists( 'opcache_get_status' ) instead and ditch extension_loaded()? This will sacrifice the Is the OPcache extension available? info though.

Hey @westonruter - if you can give advice/opinion, that would be great. Thanks in advance..

I haven't done much with Opcode Cache internals, so I don't have a lot to add. But it seems like using function_exists( 'opcache_get_status' ) is best. The specific extension which enables Opcode Cache would be nice to have as additional information, but now it would most likely always be "Zend OPcache". I'm guessing you'd have to have a list of possible such extensions in an array of strings to test for all of them to see if they are available. So I think there would be two entries:

• Is Opcode Cache enabled?
• Which Opcode Cache extension is being used?

I think this also needs a Site Health test. A site without Opcode Cache should be flagged to users as a performance problem.

[rollybueno]

Ready for testing..

Disabled:

Enabled:

[ugyensupport]

Add OPCache to Site Health

Description

Add OPCache to Site Health > Info > Server.

There is a lot of information about OPCache that can be viewed and possibly not all this information is needed at the first glance, but it will be good to have basic checks if OPCache and OPCache CLI are enabled with a link for further information.

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/9260/files

Environment

• WordPress: 6.8.2
• PHP: 8.3.14
• Server: Apache/2.4.62 (Unix) mod_wsgi/5.0.1 Python/3.12 mod_fastcgi/mod_fastcgi-SNAP-0910052141 OpenSSL/1.1.1w
• Database: mysqli (Server: 5.7.44 / Client: mysqlnd 8.3.14)
• Browser: Chrome 138.0.0.0
• OS: macOS
• Theme: Twenty Twenty-Five 1.2
• MU Plugins: None activated
• Plugins:
  • Health Check & Troubleshooting 1.7.1
  • Test Reports 1.2.0
  • WordPress Beta Tester 3.6.4

Actual Results

1. ✅ Issue resolved with ​https://github.com/WordPress/wordpress-develop/pull/9260/files

Additional Notes

Before:

After:

[abcd95]

I’ve gone through reproducing the issue and then tested the patch from ​PR 9260 with multiple configurations (OPcache enabled/disabled for both web and CLI). The Site Health Info panel displays the opcode cache status and details, and the Site Health Status test behaves as intended, flagging when no opcode cache is active.

Since the ticket already includes a thorough bug testing report with before/after screenshots, and the results match the expected behavior, I’ll proceed to remove the needs-testing label.

​Screenshot of the site health screen when the OPcache is not enabled

[shailu25]

Test Report

This Report Validates that the indicated patch addresses the issue.✅

Patch Tested: ​https://github.com/WordPress/wordpress-develop/pull/9260

Environment:

WordPress - 6.9-alpha-20250806.023428
OS - Windows
Browser - Chrome
Theme: Twenty Twenty-Five
PHP - 7.4.31
Active Plugin - None

Actual Results:

• Issue Resolved with Patch ✅ (OPcache has been added to Site Health.)

Before: ​https://prnt.sc/ef48OBZHghem
After: ​https://prnt.sc/irT3bduK_X28

[rollybueno]

Adding back the needs-testing tag for testing the feedback on ​https://github.com/WordPress/wordpress-develop/pull/9260#pullrequestreview-3111365991

It basically showing a generic error when using silence call due to possible false response if opcache.restrict_api is set, as per ​https://www.php.net/manual/en/function.opcache-get-status.php#refsect1-function.opcache-get-status-errors.

[westonruter]

@SergeyBiryukov will review and commit

[wildworks]

Since the 6.9 Beta1 release is coming soon, let's punt this ticket to 7.0.

@SergeyBiryukov will review and commit

If you can commit before Beta1, feel free to change the milestone back to 6.9.