PHP Warning: Zend OPcache API is restricted by "restrict_api"

[raamdev]

In some scenarios src/includes/closures/Shared/SysUtils.php#L85 may throw the following warning:

PHP Warning: Zend OPcache API is restricted by "restrict_api" configuration directive in /www/wp-content/plugins/comet-cache/src/includes/closures/Shared/SysUtils.php on line 85

This is most likely the result of stringent rules put in place with opcache.restrict_api. So while functionIsPossible('opcache_get_status') on the previous line, the actual call to opcache_get_status() fails with a Warning.

I recommend that we suppress these warnings with @:

    if (!is_array($status = @opcache_get_status(false)) || !$status) {
        return ($status = false);
    }

---

Referencing: https://wordpress.org/support/topic/zend-opcache-api-is-restricted

[raamdev]

@jaswsinc Any opposition to suppressing warnings from opcache_get_status() here?

[jaswrks]

I have no problem with that, no.

Alternatively, you could add a specific check for that scenario here: https://github.com/websharks/comet-cache/blob/160227/src/includes/closures/Shared/ConditionalUtils.php#L345-L347

The idea would be to check the opcache.restrict_api INI setting and then decide if the function is disabled or not. If it is, add it to the $disabled_functions array there. Then, before you call upon opcache_get_status, check if it can be called upon first.

if ($this->functionIsPossible('opcache_get_status')) {

}

[raamdev]

@jaswsinc writes...

Alternatively, you could add a specific check for that scenario here:

I like that idea better. I was just reviewing the docs for opcache.restrict_api:

opcache.restrict_api
Allows calling OPcache API functions only from PHP scripts which path is started from specified string. The default "" means no restriction.

So, to support this properly we should be checking to see if opcache.restrict_api is blank (i.e., Comet Cache will be allowed) or if opcache.restrict_api contains a path that has partial match to the path to the Comet Cache plugin.

That said, the docs are not clear on whether or not partial matches apply here, e.g., if opcache.restrict_api is set to /srv/www/ and the script is in /srv/www/wordpress/wp-content/plugins/comet-cache-pro/, will that be considered allowed? Or would the script have to literally be in /srv/www/? I assume the former behavior, but we need to run some tests to confirm.

[jaswrks]

Noting that this would make a nice addition here also.

[jaswrks]

Referencing: https://github.com/zendtech/ZendOptimizerPlus/blob/3b16ca512290b0416baf02962beedc703147a97a/zend_accelerator_module.c#L88-L98

[raamdev]

I see, so it looks like the path of the script just needs to start with the path defined in opcache.restrict_api (i.e., if opcache.restrict_api is set to /srv/www/ and the script is in /srv/www/wordpress/wp-content/plugins/comet-cache-pro/, that will be allowed).

[jaswrks]

Yes, I confirmed that locally also.

[renzms]

@raamdev @jaswsinc

Confirmed Working

When restricting Zend OPcache API by opcache.restrict_api = /foo/bar

The PHP warning does not appear in the WP Dashboard with Comet Cache active.

Double checking this with OP Cache Dashboard plugin, this shows up in the error log:

Warning: Zend OPcache API is restricted by "restrict_api" configuration directive in /app/src/wp-content/plugins/opcache/opcache.php on line 238 
Call Stack: 0.0003 389536 
1. {main}() /app/src/wp-admin/admin.php:0 0.1710 3769296 
2. do_action() /app/src/wp-admin/admin.php:222 0.1710 3769672 
3. WP_Hook->do_action() /app/src/wp-includes/plugin.php:453 0.1710 3769672 
4. WP_Hook->apply_filters() /app/src/wp-includes/class-wp-hook.php:323 0.1710 3770800 
5. OPcache_dashboard->render_admin_page() /app/src/wp-includes/class-wp-hook.php:298 0.1710 3770800 6. opcache_get_configuration() /app/src/wp-content/plugins/opcache/opcache.php:238 

[raamdev]

Comet Cache v161221 has been released and includes changes from this GitHub Issue. See the v161221 announcement for further details.

---

This issue will now be locked to further updates. If you have something to add related to this GitHub Issue, please open a new GitHub Issue and reference this one (#733).