[wp-trac] [WordPress Trac] #62946: wp_invalidate_opcache() promises more than it can do
WordPress Trac
noreply at wordpress.org
Wed Feb 12 02:28:10 UTC 2025
#62946: wp_invalidate_opcache() promises more than it can do
--------------------------+------------------------------
Reporter: kkmuffme | Owner: (none)
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: General | Version:
Severity: minor | Resolution:
Keywords: | Focuses:
--------------------------+------------------------------
Changes (by kkmuffme):
* severity: normal => minor
Comment:
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.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/62946#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list