opcache invalidation

Bug Report

• Yes, I reviewed the contribution guidelines.
• Yes, more specifically, I reviewed the guidelines on how to write clear bug reports.

Describe the current, buggy behavior

wp plugin update doesn't invalidate PHP-FPM opcache

Describe how other contributors can replicate this bug

• wp eval "wp_remote_get(<something returning a plugin version>);"
• wp plugin update <said-plugin>
• wp eval "wp_remote_get(<something returning a plugin version>);"

Describe what you would expect as the correct outcome

Output should have changed because the opcache for this script should have been invalidated.
Actual: It's the same output

Let us know what environment you are running this on

wp-cli 2.10.0 on PHP (cli/fpm) 8.2

Provide additional context/Screenshots

• wp plugin update is run in the context of the cli PHP SAPI
• It makes use of Plugin_Upgrader (wp-admin/includes/class-plugin-upgrader.php)
• This one has a wp_clean_plugins_cache taking care of transients.
• and call install_package defined by wp-admin/includes/class-wp-upgrader.php
• which makes use of move_dir which...
• calls wp_opcache_invalidate_directory

The problem is that this call is done in the context of the PHP SAPI instead of the PHP-FPM cgi PHP SAPI.

This issue was anticipated in this comment 5 years ago https://core.trac.wordpress.org/ticket/36455#comment:104

Provide a possible solution

https://github.com/gordalina/cachetool/ connects to the fcgi socket to operate on the correct SAPI. I could run the script by hand to invalidate a specific list of files/dir. But wp plugin update must then return the actual list of files which were modified/added/removed (a helper could exist for that purpose), so that the list could be passed on when wp plugin update finishes.

(But something smarter may exist, like hitting a REST API endpoint which runs the adequate wp_opcache_invalidate_directory(), to be requested after the plugins are updated like move_dir would have done?)