Do you have any custom BB-Codes appearing in the editor when you try to post a new thread?

If you only see the default BB-Codes, your BB-Code cache might be corrupt. In this case, go to AdminCP > Custom BB Codes > BB Code Manager, and click Edit for any BB-Code. Then click Save.

If you have no BB-Codes because you deleted them all, then this is the problem. In this case, you should not have deleted the ones that were installed by VaultWiki.

The problem arise when "Store CSS Stylesheets as Files" is set to "Yes"

Nope, there is a definite difference in the way it renders the page.

thincom2000, can you look into this issue again?

Have you upgraded VaultWiki or vBulletin at all since this started happening? If you were using CSS files during the upgrade, it should have rebuilt them. The only way this would happen for CSS files, and not for inline CSS too, is if your CSS file cache is not up-to-date.

Try visiting vault/install/finalupgrade.php while CSS is enabled, and run through the process. You may have to clear your browser cache as well.

I am still not experiencing any issue on my test site and I'm storing CSS as files...

Started with:
VaultWiki v3.0.0 Lite - vBulletin? Version 4.0.2
At the moment on:
VaultWiki v3.0.6 Lite - vBulletin? Version 4.0.6
Would say had quite a lot of version "upgrades" during this time!

Cleared all "browser cache" run vault/install/finalupgrade.php while CSS is enabled, no difference at all, problem still there.

When "IE8 Compatibility View" is on, the page renders correctly with storing CSS as files to Yess, otherwise not.

This occurs only in Internet Explorer 9 beta when using a Document mode that doesn't match your Browser mode. This causes problems parsing the Internet-Explorer conditional tags because the browser now has 2 conflicting version numbers.

Make sure the Developer Tools menu is open when you are changing versions and you'll see that the option "Force IEx Document mode" doesn't change the version numbers correctly. You want to change both versions from this toolbox together.

I think the Document mode affects DOM parsing, and the Browser mode affects CSS/JS parsing. If these two numbers are out of sync, then yes, you will have problems.

If the Document number is too high, conditionals for style (CSS) tags that only affect IE7 won't parse.
If the Browser number is still IE7, then it will follow IE7 CSS rules, but doesn't have them because the style tag wasn't parsed.

If the Document number is too low, conditionals for style (CSS) tags that only affect IE7 will parse.
If the Browser number is still IE9, then it will follow IE9 CSS rules, but the IE7 rules were loaded above, and IE7 CSS is "broken" in non-IE7 Browsers.

This isn't something VaultWiki has control over, it's just something you have to keep an eye on when you're messing with your Debug menu.

Yip, but it does not account for FF or any of the other browers doing the same with the css.

A quick fix for this problem would be to copy vw-tabbed.css into the additional.css, (this rectifies the problem, and shows that there is a problem with "/vault/special_plugins_css.php") but how do you disable vw-tabbed.css in this case?

Hope this leads you to the root of this problem, and a stable fix!

I have been using the commercial version for a few months, and while there is a bit of a learning curve with the product, it runs well, integrates flawlessly, and support has always been johnny on te spot with an answer.

Just released 3.0.7, which fixes the following issues:

- infinite redirect for URL with space after colon
- Title with entities always counts as changed
- article missing after AJAX title edit
- flood check breaks inline moderation
- CSS order when stored as files
- TABLE BB-Code creates broken HTML

thank you for update

Thanks! :)