Issue: Vaultwiki - unexpected file content errors

Yes, assuming you downloaded VaultWiki 4.1.9 for both XF 2.2 and then later 2.3, this is probably caused by a caching mechanism in our download system...

Because VaultWiki contains files that may be slightly different depending on which customer downloads them, the file hashes for a customer's files are also unique and cannot be predetermined when we create a new version. Instead, when you download VaultWiki, the file hashes that XenForo uses to check for "unexpected contents" are generated by our server at the time you request the files. Because our site provides options to only include various subsets of the package contents, and to speed up future download times, we cache the file hashes for use on subsequent downloads of the same VaultWiki version.

However, this gets wonky when downloading the same VaultWiki version for different versions of XenForo, if those XenForo versions actually have slightly different file contents with the same target file name. For example, in XenForo 2.3, the style_properties.xml file is in a different format from earlier versions due to the new light/dark style variants. Similarly, there are changes to various templates.xml contents based on style updates in core XenForo. And addon.json contains an integer version number for VaultWiki, which must be slightly different between 2.2 and 2.3 versions, or XenForo will not trigger the ability to upgrade from 2.2 to 2.3 VaultWiki.

All this to say, I would expect the file hashes not to match and to receive an "unexpected contents" warning for these files if upgrading from VaultWiki for XenForo 2.2 to 2.3, using the same VaultWiki version number.

I've made some changes to our download system to ensure these files will compare hashes based on the hash of the source file (dependent on the XF version choice) rather than the target file name (e.g. always being templates.xml). However, this will not resolve hash mismatches from our download system in all cases. For example, if the downloader chooses options like minified Javascript one time, then unminified the next, the hashes will not match. In order to resolve situations like these, some more structural changes would be required to the download system, which will have to be put off to a future time. Since it resolves the specific files you mentioned, however, I am marking this issue as fixed.

Thank you for the explanation. I am assuming that the next version of VaultWiki, when I download it for XF 2.3, will resolve this issue.