Issue: Uncaught ReferenceError: $ is not defined at bbcode.js?v=0be8a32c:1

This has to do with CloudFlare's RocketLoader loading all your Javascripts after the VaultWiki scripts were already loaded. Since VaultWiki's Javascript relies on xenforo.js and jquery.js which are normally loaded within the HEAD-tag, this is a problem. VaultWiki scripts are excluded from RocketLoader since VW 4.0.14, because of bugs in RocketLoader at that time. It is also unnecessary to rocketload VaultWiki scripts because they are already loaded on a deferred basis or at the end of the HTML.

In order to avoid the issue, if you have control over the rocketloader output:
- you can remove the "defer" attribute from the script-tag for rocketloader.js. It is not actually needed since it is the last element in the HTML anyway, and doing this will preserve the load order;
- OR if the rocketloader tag is added by a XenForo add-on, and you don't want to modify the tag, you can try changing the execution order of the listener responsible so that it executes before the VaultWiki listeners (which would run the rocketloader scripts before VaultWiki scripts).
- OR if it is an option, you can also try to position the rocketloader tag manually in your style.

If you cannot change the rocketloader tag, your next options in the short term are to (pick one):
- Add data-cfasync="false" to the script tags for xenforo.js and jquery, which are dependencies of VaultWiki. All dependencies of excluded scripts should also be excluded (see: https://support.cloudflare.com/hc/en...c-JavaScripts-)
- Use rocketloader manually only (add data-cfasync="true" to the specific script tags that should be deferred -- not including xenforo.js or jquery).
- Don't use rocketloader.

I will need to research the origins for the change in 4.0.14 and see if the situation has improved at all since then which would make it compatible with VaultWiki now or if there is another workaround available. Otherwise, we can try to resolve this ourselves by forcing XenForo scripts that are dependencies to also be excluded from RocketLoader.

The best solution, if it is not already possible, is for rocketloader devs to allow you to position the rocketloader tag manually, in case you want something else between it and the closing HTML-tag (read: other "defer" scripts that were excluded from rocketloader but that expected rocketloaded dependencies to load first).

---
As for your "spammy" threads, I can see this for the first example. If I received an email that looked like the first post, or a member posted that on my site, I would think it was spam. The post has short or incomplete sentences, and it includes terms which usually trigger anti-spam rules. Since it is the first post, it is used by XenForo to form the meta/microdata descriptions as well. I'm not sure what you can do about this situation, as the post is actually in-context for your site's subject matter. In the tool that showed this result, does Google provide you a way to say that it is a false positive, or that you reviewed it and that the content is in the proper context?

https://support.cloudflare.com/hc/en...c-JavaScripts-
Is there a way to do this for the relevant xf js?

In the template page_container_js_head, you would modify all script-tags there so that the attribute data-cfasync="false" appears as the first attribute of each tag.

I have found little documentation of the original issue, but my memory has begun to suggest that RocketLoader was blocked due to it garbling already-minified scripts when it tried to minify them again and/or timing issues. However, based on encounters with more current versions of RocketLoader, it looks like it would be better at avoiding timing issues, and VaultWiki's scripts were also redesigned in 4.1.x to be more resilient to timing issues. Furthermore, VaultWiki 4.1.x includes an option to serve the unminified Javascript which could avoid double-minify issues by allowing RocketLoader to minify the original Javascript.

As of 4.1.0 Beta 3 build 003, RocketLoader protection will be tentatively removed, so VaultWiki scripts will be possibly picked up by RocketLoader. If there are major problems that can only be resolved by modifying RocketLoader, then the protection can be re-added in a future build.

Basically $ is an alias of jQuery() so when you try to call/access it before declaring the function, it will endup throwing this $ is not defined error . This usually indicates that jQuery is not loaded and JavaScript does not recognize the $. Even with $(document).ready , $ is still going to be undefined because jquery hasn't loaded yet.

To solve this error:

Load the jQuery library at the beginning of all your javascript files/scripts which uses $ or jQuery, so that $ can be identified in scripts .

There can be multiple other reasons for this issue:

• Path to jQuery library you included is not correct
• The jQuery library file is corrupted
• Working offline
• Conflict with Other Libraries

As explained above, this was a problem of RocketLoader, which is not part of XenForo or VaultWiki, rearranging scripts so that jQuery was no longer at the beginning of all javascript files. If you are having this issue, you might consider disabling RocketLoader.