[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