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.