Updated response to address the questions as asked.
Yes, either the web server need to be restarted or the web-server's OPCache needs to be cleared. Drush cannot clear the web-server's opcache as it is a CLI application. Instead of restarting the web server a php script with following content can be added to next to Drupal's update.php
<?php
opcache_reset( );
/*
Following measures should be taken to safeguard this file from malicious use
a) Set filename with a long random string as a name (like 100+ characters).
b) Check the IP address of the requester so the script can only be called from trusted networks.
To clear cache visit this file at
siteurl/random_long_string_eiquooR3.php
or use curl siteurl/random_long_string_eiquooR3.php
Check the IP address of the requester so it can only be called from trusted networks.
*/
Neither Drupal core nor Drush invalidate OPCache.
Yes, setting opcache.enable_cli to 0 is a fine, it is anyways off by default. Unless you are really explicit in your configuration of opcache to enable it on the cli and also use a file based caching mechanism, the opcache exists in memory and is reset on each command line invocation. Therefore you only need to worry about clearing opcache by restarting any long-running PHP command line jobs.
Original Answer by @greggles
- Restarting the webserver works, but takes quite some time. A more efficient solution is to have a way to call opcache_reset.
- Opcache must be reset by calling
opcache_reset
from within the web process. If you call it inside drush then it will not clear the opcache for the webserver so it won't help the problem.
- Unless you are really explicit in your configuration of opcache to enable it on the cli and also use a file based caching mechanism, the opcache exists in memory and is reset on each command line invocation. Therefore you only need to worry about clearing opcache by restarting any long-running PHP command line jobs.
If you want to clear opcache as part of a deploy process, I suggest adding a file that contains opcache_reset
and then you have to protect access to that file so malicious users can't easily call it:
- Give it a long random string as a name (like 100+ characters).
- Check the IP address of the requester it can only be called from trusted networks.