With opcache.enable_cli
being set to 0, it means the CLI doesn't use the OPcache. So invalidating the cache isn't going to change anything for CLI. Even if you change that to use the opcache via the CLI, it's still not going to invalidate the cache for you automatically if a file get written (writing a PHP file is a completely different thing than executing a PHP file).
If the opcode cache isn't updating when files change, you probably changed the opcache.revalidate_freq
option from it's default of 2. The issue with setting opcache.revalidate_freq
to 0 (never check if a file has changed) is that there are a TON of ways PHP files can change, so trying to account for all of those manually (making sure you invalidate the cache any time you copy a PHP file for example) is an almost impossible task.
If you really don't want to check if files have changed, you could raise it to 60 seconds or something. That way in a worst case scenario where you forgot to invalidate the cache manually for something, it would take a maximum of 60 seconds before the new PHP file showed up.
That being said, if you override the opcache to not revalidate file changes (it does by default), you are going to need to make sure you invalidate the cache on your end when you want to (since you've disabled it's ability to do it automatically by default).