Issue: Conflict with XMG comments

Are you receiving any error in the browser console, when comments are supposed to load, or does anything appear in your error logs at the time?

Only this error, which is present when I turn VW off and comment work:

TypeError: XenForo.BbCodeWysiwygEditor is undefined
http://domain.com/js/Tinhte/XenTag/b...js?_v=f7c52214
Line 2

I think there is an issue with VaultWiki being unable to detect the proper output encoding for XMG comments. Most Javascript-loaded HTML in XenForo is transmitted via JSON requests, and these are usually crafted a certain way. It's possible XMG crafts these requests differently or encodes the output differently. If this is the case, VaultWiki probably uses a different output encoding when it tries to add its own integrations to the output.

I have sent a PM with a little more information.

Fixed in the next release. This is due to a variation in how XenForo executes Javascript between normal HTML output and JSON output. In HTML output, Javascript is executed in an expected order from script tag to script tag.

However, in a JSON request, individual Javascript files are loaded asynchronously, and then executed in the order of whatever scripts finish loading first. In my opinion this is an oversight -- all asynchronously loaded scripts should wait for the other scripts in the current batch so they can execute in the requested order. This is the way VaultWiki handles its own async scripts. While I contest that this is a small design flaw within XenForo, I have modified VaultWiki's redactor files for the next release so that they can at least fail and break VaultWiki editor functions silently in this case, rather than preventing the entire JSON action from completely.

XMG 2.1 RC6 fixes this issue.

While I suspect this particular presentation of the issue might be fixed by a change to XMG, perhaps the method it uses to load comments (not really a reason to be using deferred loading on a default-open tab, unless comments are updated live)...

This issue should actually extend to anywhere that XenForo (or an add-on) loads an editor asynchronously, commonly inline post editing, and this is a core issue that can only be resolved by either changing VaultWiki or XenForo (although changing VaultWiki would be a "workaround" and not a fix for the underlying issue). VaultWiki expects script tags to execute in the order it provides, and XenForo executes script tags in whatever order it feels like.

As mentioned above, there is a workaround that will be employed in the next release: don't load VaultWiki editor stuffs if XenForo is doing something asynchronous. This might lead to lost functionality, but currently is the only way to go about it due to non-existent Javascript events at the appropriate position.

A true fix would be for XenForo to update its asynchronous loader to be queue-based, rather than execute-when-loaded. This can still be achieved asynchronously, without any real added latency:
1. Asynchronously load included scripts to memory.
2. As each script is loaded, add the result to a queue in the original order.
3. Execute the ordered queue.
As it is now, there is no queue and no order, which can cause Javascript conflicts (X-dependency is not loaded yet, etc, even though it was first in the chain).