opcache invalidation

[drzraf]

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?)

[swissspidy]

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.

Just noting that this is probably relevant for other types of updates too.

(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?)

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]

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.

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 like wp plugin update --show-changed-files ?

¹ Declaring it under a REST endpoint could be even nicer btw

[swissspidy]

Isn't that something wp-cli could do (to avoid doing a full reset of the opcache when only one plugin was updated). Something like wp plugin update --show-changed-files ?

Possibly. The wp_opcache_invalidate_file filter 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]

#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]

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]

Note that this would also need to be implemented for the language command, as there are PHP translation files.

[swissspidy]

Inclined to close this as a wontfix for now given the added complexity and limited use case

[drzraf]

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:

• "lack of implementation results from lack of interest/usage"
• "lack of usage results from lack of an implementation" (or if interest isn't mainstream yet)

I still think the package modification information is valuable.