E_WARNING: Zend OPcache API is restricted by "restrict_api" configuration directive

Hi Steve,

Just did some research online and appears that that error is related to OpCode Cache being used on the server which disables some PHP functions:
opcache_compile_file()
opcache_get_configuration()
opcache_get_status()
opcache_invalidate()
opcache_reset()

Can you contact Rackspace and ask them to disable OpCode Cache for the site or at least for the CMS Builder folder if that is possible?

Hi Damon,

Thank you for the information. I spoke with Rackspace tech again, and they confirmed with their operations team that the ability to control opcache was disabled the other day.

On their cloud service opcache is enabled by default. Even though opcache can be turned off via htaccess and their operations team disabled the ability to control opcache, the php functions related to opcache are still enabled (yet won't do anything due to the configuration change - which makes no sense to me at all).

I'm currently awaiting a response from my last comment in the support ticket thread stating that this would effectively force us to disable opcache on all the cloud hosted sites, yet would still log error warnings because the php function is still enabled.

I doubt they will make any configuration changes, but will await a response and keep you posted.

Regards,
Steve

Hey Steve, 

Can you try hiding the warning by adding an @ before the second instance of opcache_, like this: 

if (function_exists('opcache_invalidate')) { @opcache_invalidate($filepath, true); }

After making that change, check if warnings no longer appear in the error logs, and check if after you update a schema (such as by adding a field or changing a field label) it doesn't show you the old cached versions.

Let me know if that works for you and any questions.  Thanks!

Hey Dave,

Suppressing with @ operator effectively keeps the warning out of the log.

Adding the following to either the root htaccess or cmsb folder htaccess disabled opcaching:
php_flag opcache.enable Off

We can certainly work with this recent configuration change by the host. Will just have to make sure we disable opcache on every site and add the suppression operator to that line on all our installations. It's just annoying that the host changed configuration so there's no opcache controls, it's enabled by default, and the php functions are still enabled - yet won't do anything because the actual controls are disabled.

Thanks again,

Steve

Hey Steve, 

Yea, we deal with issues like this with hosting providers all the time, so I get it.  

Let me know if there's anything else we can add to the CMS or things you're trying to accomplish that you can't with the new configuration.

For our part, the reason we had that code was because on some servers users were updating their sections/schemas and when the script reloaded it would show the old cached version (eg: newly added fields wouldn't show).  So that's a possible problem that will still occur.

If they haven't disabled opcache_compile_file() or opcache_reset() we could use that.

And you could double check that you can't override "opcache.restrict-api" (to re-allow opcache* functions) in /cmsb/.htaccess or /cmsb/php.ini.  Not all hosts parse the /cmsb/php.ini but some do.  And you normally can't set that value in .htaccess, but some cloud hosting setups manually parse .htaccess files in a way that lets you set things you normally can't.  You can see the value of opcache.restrict-api in the left colmn here: admin.php?menu=admin&action=phpinfo
Reference: http://php.net/manual/en/opcache.configuration.php#ini.opcache.restrict-api

Let me know how it goes.

Hey Dave,

Right, and that code is certainly best practice to ensure the cached files are updated.

We'll have to disable opcache entirely on the installs in RS cloud. Findings indicate the functions for opcache are enabled, yet restricted. Apparently the cache was related to the entire web cluster, not just users - hence why they've restricted said functionality. They'll probably disable the functions on future php builds released to the platform, unless they revise caching implementation to be on a user basis which I don't see happening in the near future.

It's one of those trade-offs when going to public cloud solutions.

Appreciate the assistance.

Cheers,
Steve

Hi Steve, 

You could check to see if the server is returning a 404 or error for any of the CSS files.  That would be my first guess.

In Chrome:

• Ctrl-Shift-i (open Developer Tools)
• Click on Network tab
• F5 to refresh page
• Check if the status on any of the loaded files isn't 200

And/or try not disabling opcache via htaccess.  

It sounds like a server issue, but we'd like to support however rackspace is doing things, so if you'd like me to take a look just email me direct at dave@interactivetools.com (don't post any login details to the forum).  Thanks!

Hey Dave,

That was my first thought too, but they're all returning 200. Also tested with opcache enabled.

Will compile test server info and email you shortly. Thanks again Dave.

Steve