wp_opcache_invalidate() promises more than it can do

[kkmuffme]

wp_invalidate_opcache() (tries to) flush the in-memory opcache and by doing so, accidentally introduces side-effects that most WP users won't be aware of.

1) if opcache.file_cache is used, the invalidated file will reload it's PREVIOUS (before invalidation) opcache data when PHP-FPM is restarted or the opcache reset

When using opcache.file_cache and opcache.enable_cli=1, this means that all CLI requests still operate using the old files, while the PHP-FPM requests run on the new files.

2) if wp_invalidate_opcache() is called in CLI, it won't have any effect (except for the current request if opcache.enable_cli=1 is used for the current request itself), since the CLI SAPI doesn't have shared memory with the FPM SAPI

This means that currently all CLI requests run on the new code, while PHP-FPM still runs the old.
Which essentially makes wp_invalidate_opcache useless and in fact will lead to confusion and issues especially when using WP CLI to update core/plugins/themes.

[swissspidy]

I don‘t think the function promises anything about CLI. For such cases I‘d recommend something like ​https://github.com/wearerequired/wp-cli-clear-opcache

[kkmuffme]

If you look at the original ticket, it was about resolving opcache cache issues. However, this hasn't been achieved. If plugins/core are updated in CLI (e.g. in cron) it's still the "old" behavior and the FPM opcache isn't invalidated.

The introduction of this function made the initial issue worse than before, bc now you can end up with more different possible opcache situations than before.

It's not an issue we have (since we need multi-server handling anyway, which also handles opcache flushing correctly), but it's something I've been asked twice now within a short time frame from casual WP users.

What I mean to say is that at least for any places WP uses it for upgrading core in a CLI sapi, it might make sense to hook an action to also invalidate whatever file on the first non-CLI request?
And ideally also flush it from the file_cache directory

But again, it's not important to me - possibly just outlining the caveats in the docs of that function might suffice.

This PR addresses issues with opcache invalidation in WordPress, specifically:

Changes made:

• Added CLI SAPI detection and handling
• Added file cache configuration detection
• Implemented flag file system for cross-SAPI communication
• Added complete cache reset for file cache scenarios
• Maintained existing WordPress coding standards and functionality

Trac ticket: https://core.trac.wordpress.org/ticket/62946

Referencing PR: #8313
Improved formatting of the code.
Trac ticket: https://core.trac.wordpress.org/ticket/62946