I have tested this item ✅ successfully on 9fd4766

I've tested lots of updates on that environment where I most of the times can reproduce the issue and could also today.

With the PR applied before the update, the issue did not happen anymore.

@nikosdion Do you think that a similar change in the J4 extract.php could make sense? I don't see there that we do there what this PR here does. Or is that just at another place?

Joomla 4's extract.php already does that. The benefits of creating a purpose-built extraction feature instead of reusing generic code that's really written for restoring backups on empty servers ;)

Joomla 4's extract.php already does that. The benefits of creating a purpose-built extraction feature instead of reusing generic code that's really written for restoring backups on empty servers ;)

@nikosdion Hmm, I did not see we do it on all extracted PHP files. But maybe I've just missed that when having looked quickly into the code.

@richard67 Look at ZIPExtraction::processLastExtractedFile which is called after we're done extracting a file. It calls clearFileInOPCache which calls opcache_invalidate for files with a .php extension. I think that you can follow the code backwards and reference the (documented!) constants to understand how it works.

@richard67 Look at ZIPExtraction::processLastExtractedFile which is called after we're done extracting a file. It calls clearFileInOPCache which calls opcache_invalidate for files with a .php extension. I think that you can follow the code backwards and reference the (documented!) constants to understand how it works.

@nikosdion Thanks. Found it. Seems indeed to be ok.

I have tested this item ✅ successfully on 9fd4766

I have just tested on my setup too so I think we are good to go here. Thanks @nikosdion 😄

Yes, I tested again today to make sure it also works on odd and not only even days on my weird environment, and it was all fine 😄 .