Repository navigation
opcache invalidation #444
Description
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 updateis run in the context of thecliPHP SAPI- It makes use of
Plugin_Upgrader(wp-admin/includes/class-plugin-upgrader.php) - This one has a
wp_clean_plugins_cachetaking care of transients. - and call
install_packagedefined bywp-admin/includes/class-wp-upgrader.php - which makes use of
move_dirwhich... - 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?)
Activity
swissspidy commentedon Mar 12, 2025
Just noting that this is probably relevant for other types of updates too.
In the past I‘ve recommended https://github.com/wearerequired/wp-cli-clear-opcache for this. It‘s not something WP-CLI can provide out of the box since it requires a change on the WordPress side.
drzraf commentedon Mar 12, 2025
Ok, I didn't knew about this plugin. It's exactly the right way to do it (at least the best one given current limitations). ¹
But in order to run
wp opcache invalidate 'foo/bar.php', we need to know which files were impacted by the update-process. Isn't that something wp-cli could do (to avoid doing a full reset of the opcache when only one plugin was updated). Something likewp plugin update --show-changed-files?¹ Declaring it under a REST endpoint could be even nicer btw
swissspidy commentedon Mar 14, 2025
Possibly. The
wp_opcache_invalidate_filefilter could potentially be (mis-)used for that. If you're up for writing a quick proof of concept PR then this could be discussed further to see if it's a valuable addition to WP-CLI.swissspidy commentedon Feb 15, 2026
#501 is a proof of concept for this.
Not sure if the output should be part of the command though or if this is better just exposed via a hook for extensions to consume.
swissspidy commentedon Mar 10, 2026
I changed #501 now to expose the data via a hook, so that a package like https://github.com/wearerequired/wp-cli-clear-opcache could hook into this process and perform validation.
@drzraf would that work for your use case?
swissspidy commentedon Mar 11, 2026
Note that this would also need to be implemented for the language command, as there are PHP translation files.
swissspidy commentedon Apr 8, 2026
Inclined to close this as a wontfix for now given the added complexity and limited use case
drzraf commentedon Apr 8, 2026
Sorry for not replying earlier. The use-case is "limited"... but to any WP instance aiming at performances (opcache is an obvious part of such consideration)
The problem with opcache now is that we can't selectively clear the cache because we are not provided with granular update information albeit known by WordPress. It'd help opcache today. Could help malware detection or sandboxing tomorrow.
It's sometimes difficult to determinate whether:
I still think the package modification information is valuable.
swissspidy commentedon May 8, 2026
Most folks I know manage their sites via Composer these days and don't perform updates via WP-CLI. Even when doing it via WP-CLI, there are usually so many updates (plugins, themes, core, translations), that the granular invalidation would become a bit tedious. At which point https://github.com/wearerequired/wp-cli-clear-opcache with
wp opcache clearis a simpler solution.I'd love to hear some other perspectives on this though, my opinion is not set in stone :)
drzraf commentedon May 9, 2026
A bit off-topic, but I use a mix of composer + automated
wp-cli plugin updatefor patch release. The reason being that composer is a PITA in many regards: there are so many ways you can break an installation: Network connectivity issue during fetching = broken installation (because composer removes packages before having any guarantee the new one fits). If a package got wrongly removed by composer,composer reinstallbecomes no-ops,composer-patches&composer-merge-plugin, hooks (and permissions) entering the game also add their own possibilities of failures. I've foundwp-cli plugin updateto be so much more reliable.