VaultWiki 4 Gamma 7

We are pleased to announce today's release of VaultWiki 4 Gamma 7, now available for download. Gamma 7 is primarily a maintenance release, but resolving some performance issues and regressions of VaultWiki 3 behavior that has gone addressed so far. We intend to continue resolving such long-standing regressions over the next few releases.

A small number of high-priority bugs have been resolved, most notably:

• New pages entering the moderation queue lose their titles and text

BB-Code Caching

With Gamma 7, the contents of wiki pages and comments are finally saved in a BB-Code cache for later, so that the parser doesn't need to re-interpret the BB-Code every time the page is loaded. Once the cache is primed, this results in significant improvements to PHP page generation times, typically 15 - 25%.

It should be noted that VaultWiki uses a different BB-Code caching system than either vBulletin or XenForo, due to the potential complexity of a wiki page and the information that must be stored. Because of this, any maintenance tools that affect the forum's BB-Code cache will not automatically affect the wiki's cache too.

HTML5

With Gamma 7, VaultWiki 4 now serves all wiki pages as HTML5 documents, regardless of the default doctype of the forum platform. Due to mixing of doctypes in vBulletin, this change causes a known issue with VaultWiki pages, as well as some forum pages, not fully validating as either XHTML 1.0 or HTML5 when using third-party validation tools. However, this change has allowed us to implement other features that are only available under HTML5, so we believe this has been an acceptable trade-off.

Microdata

With the change to HTML5, VaultWiki 4 now makes full use of microdata in wiki pages and related documents. Microdata is a form of metadata that is embedded within the content of a web page and that many search engines now use to improve their search results. The additional metadata provided by microdata in VaultWiki 4 should result in increased relevance scores, more detailed search listings, and theoretically, higher ranked pages.

Page Rank

VaultWiki 3 performed remarkably well at telling search engines which wiki pages and related wiki documents were important and preventing search engines from indexing or even accessing unimportant pages. Before Gamma 7, VaultWiki 4 regressed in this department, allowing search engines access anywhere that allowed guests and relying only on sitemaps to tell search engines what pages were important.

This was a serious problem for SEO, because your most important wiki pages could be indexed together with trivial ones like the History tab or a Special page. In the search results, a user might be presented with both, the trivial one, or neither, since the perceived importance of the important wiki page was diluted by the presence of the other results.

As of Gamma 7, VaultWiki 4 should now even outperform its predecessor. Not only does VaultWiki now restrict crawling to actual wiki pages, but it restricts crawling to wiki pages that actually have some form of content. If a wiki page is empty, has no child pages, and no comments, it will now just be ignored by search engines.

In addition to this, a new Area setting lets you choose whether to allow indexing of any content within an area at all. So for example, if you store all your stubs or templates in one area, you can prevent search engines from seeing them at all.

CSS Changes

Before Gamma 7, all of the CSS for wiki pages was stored in one style template called vw.css. Over several releases, the template quickly became long and unwieldy, making simple CSS modifications difficult for users (and developers). If a modification was made, it was likely invalidated in the next upgrade. This was particularly a pain point for vBulletin users, who would have to manually update their templates again.

In Gamma 7, we have separated vw.css into several smaller templates that are named based on what they deal with, e.g. vw-popup.css deals with pop-up menus and vw-tab.css deals with the styling of wiki tabs. This should not only make finding the CSS you want to change a little more straightforward, but if you do modify vw-tab.css, a change in the next release to vw-popup.css won't affect what you did.

That said, direct modification of the CSS should no longer be necessary. Gamma 7 introduces the vw-additional.css template, which has no default content. This template will always be loaded after all other CSS, so you can make any customizations by adding them to this template. For vBulletin users, this is ideal to modifying vBulletin's own additional.css, because vw-additional.css is only loaded when wiki styles get used.

The separation of the CSS allows loading portions of the code modularly. On many pages, this means that the number of bytes transferred for wiki CSS is lower than earlier versions of VaultWiki 4, which loaded all CSS on every page. This will typically mean reduced bandwidth and page render times compared to earlier releases.

We've also added a CSS caching system which is arguably superior to traditional style-modified-time CSS caching, such as vBulletin's CSS roll-up system. At page access time, Gamma 7 loads an uncached version of the CSS based on what templates are needed for the current page, rather than a pre-defined roll-up, and caches this result. Then, if the same templates are used in a subsequent request by any user, the cached version is used. Subsequent requests are able to load the CSS file directly rather than proxying through PHP again, which means the overhead of using PHP is eliminated for most CSS requests and any server-side performance benefits of using static assets can be realized.

Release Notes

VaultWiki 4 Gamma 7 should be usable on vBulletin-based and XenForo-based production sites.

We maintain the Gamma status due to the significant style changes that still require more real-world testing.