This report has been closed as being a XenForo bug. I have done some research into the code for XenForo's add-on archive handler and tldr it contains a design flaw. The issue should be reported to them. I have included the relevant information at the end of this post. In between, I explain how opcache works, and why everyone really needs to add opcache management to their process for software updates.
Re: Litespeed Cache, it caches the final HTML response from XenForo. It is not a PHP opcache, like PHP's default Zend Opcache (with settings like opcache.revalidate_freq set in your php.ini).
A traditional PHP opcache caches the contents of an individual PHP file as machine code. If the PHP file changes and the opcache has not been cleared, then you are still running code from the older version of the PHP file, even though you changed the file.
It is possible that this may not cause error messages every time, but it can lead to data corruption if you run new code from one file against old code from another file. Possibly because VaultWiki is a large add-on, you are more likely to encounter an issue where your cache might update while only half the files are finished uploading / unpacking. This seems to be the situation in your opening post. Because you are using an updated file that is calling a ::saveCache method, but the file that defines ::saveCache is not available on your server yet, even though it exists in the package you are uploading.
For smaller add-ons this may not appear to be an issue, because all the files can be uploaded / unpacked quickly. But you can still encounter a situation where you are running code in a brand new upgrade script (that did not exist before and so doesn't have a cached version) against old existing files (rather than updated existing files), if you start the upgrade process before the next cache refresh. If database queries or other important logic changed, this can give you unexplainable behavior.
If your opcache is set to a long lifetime, then the only solution to avoid these situations is to add temporarily disabling it and / or clearing it to your normal upgrade process. For many VaultWiki upgrades or merely when manually editing a file, you have posted an error message that was due to your opcache being in a stale or inconsistent state, so it is not merely a theoretical issue for you.
If you don't want to go through the hassle of changing your opcache settings and restarting your PHP server (not the web server) multiple times when updating software, a simple PHP script like this can be used instead:
Code:
<?php
opcache_reset();
exit;
During a theoretical upgrade:
- Upload the files and/or unzip them into place.
- Run the opcache_reset script now that the files are in place.
- Go to the AdminCP and click the button to upgrade the add-on.
In between #1 and #2, it is still possible to encounter outlandish error messages.
XenForo bug: I have looked into it and XenForo's batch install from archive DOES reset the opcache as one of the steps, but the copy-files step is batched. This probably works fine in many small add-ons that can finish unzipping and copying files in less than the timeout before a page refresh. However, because VaultWiki contains thousands of files, it can take at least 1 refresh to copy all the files. If VaultWiki is active at the time, this means that your opcache may have automatically timed out while the files were only partially uploaded, running some old files and some new files after a refresh (the problem is worse if you have no opcache at all).
There is one huge problem with XenForo's approach:
- The add-on being unzipped should be automatically disabled and the page refreshed before copying any of the add-on's files, to avoid a situation where the add-on runs during a refresh and only half the new files have been copied.
If XenForo fixed that one thing, it would eliminate the issue you had in your first post -- assuming you used the XenForo archive installer -- if you uploaded manually, you would need to clear the opcache manually (see script earlier in this post).
In the mean time, another way to avoid this problem is to manually disable an add-on before using XenForo's archive feature to upgrade that add-on.
I should also note that it has been in the VaultWiki upgrade docs since April 2016 that you should disable VaultWiki before starting to upload new files during an upgrade:
https://www.vaultwiki.org/pages/Help...our-Web-Server