Is VW compatible with XFES, Redis and LiteSpeed Cache?

Does Vaultwiki work with:

• XenForo Enhanced Search (Elastic Search 5.2)
• Redis Cache
• LiteSpeed Cache

What settings are required advised?

According to XenForo devs, nothing special is required for an add-on to use XF-ES; that is handled entirely by XenForo. Several other customers are using XF-ES with VaultWiki and have not reported any problem there.

As for Redis and LiteSpeed, I am not familiar enough with these caches to give you an answer on that. I have not heard of any problems before. If you make any special rules for attachment routes, you can include /wiki-asset and /wiki-image there.

If you use Litespeed with mod_cloudflare, there is a known bug in Cloudflare's CSS-minify feature that Cloudflare devs have not fixed for over a year now. Their cache process crashes if it encounters certain sequences in CSS; these sequences are used by VaultWiki. If you use Cloudflare, you should not use CSS-minify, at least until their changelogs specify that the @supports bug has been fixed.

If you use PHP's Zend Opcache, do not enable opcache.fast_shutdown. It has been broken since 2013 and causes the PHP<->webserver connection to break at random times, often during HTML-streams, such as VaultWiki's install/upgrade/import.

I thought that VW is not a true addon but more of an integrated stand alone application.

I see that VW has a separate cache prefix which makes me think this needs to be set separately for redis and LSC. The litespeed team is active on xenforo.com
I have asked them here: https://xenforo.com/community/thread...1#post-1133309
Maybe its good to reach out to them.

I am not using cloudfare.
opcache.fast_shutdown is turned off.

I'm not really sure where the line would be drawn, but it is a true add-on that comes bundled with an API so that the basic wiki functionality does not need to be completely rewritten for vBulletin vs XenForo, etc. While there have been ideas thrown around to make VaultWiki capable of standalone operation (essentially by developing a separate app that uses the same API), it is not at this time. I think the only thing that might lead people to think that VaultWiki is not a true add-on is the installation process. But we had to make the installation process like that or most people's servers would timeout during large upgrades. That is really the only reason. At this time, neither vBulletin nor XenForo supports batched install or upgrade processes using their XML importers.

As for the cache prefix, VW_CACHE_PREFIX is used internally by VaultWiki for a small number of its own caches, which at this time are file-based, and apply more to vBulletin than to XenForo. You really only need it if you run multiple VaultWiki instances from the same directory (like we do during development), so that there are no conflicts in the file-system cache for site config settings or rendered CSS.

mhm. Today my site crashed on a Redis issue. I got a error that mentioned various Redis processes and VW.
I run these addons:
https://xenforo.com/community/resour...is-cache.3965/
https://xenforo.com/community/resour...counters.4366/
https://www.vaultwiki.org/issue.php?issueid=4915

After I disabled VW and flushed Redis my board worked again. I know this is too vague act upon.
But this makes me wonder if VW will not fail on a Redis enabled site?

If your Redis instance crashed, your Redis logs would probably be more useful than any XenForo error messages. You should have the memory-state from crash time as an archive that you can run a backtrace on and follow up on the issue with the developers of Redis.

It's not like VaultWiki dumps crazy values to the cache. We cache strings and integers; some are larger than others, but nothing that a single MySQL transaction can handle should cause your Redis instance to crash. Even if the value we use is ridiculous, the expected behavior of a properly functioning Redis would be to reject it rather than crash.

I dont think redis crashes. Users get a whitescreen with the message 'an error has occurred'.

Whether it crashes or not, Redis becomes non-responsive, or does not respond in a timely enough manner, as evidenced by the error messages you saw in the XenForo log: "CredisException: read error on connection - library/Redis/lib/Credis/Client.php"
Perhaps I am misinterpeting the error (the author of Credis would know more), but it sounds like XenForo's Zend Cache instance was unable to establish a connection to your Redis instance.