Better separate VaultWiki and rest of forums

I know some people want a tighter integration of VaultWiki with the regular forums - using VaultWiki bbcodes and templates everywhere, etc. I guess it's the reason for any forumdisplay page to include 4 VaultWiki .php files. And any showthread page _always_ includes the whopping 8 VaultWiki files, totalling 9000 lines as of 3.0.0 RC3!

However I suspect many are also not interested in using Wiki's templates or its other features in the regular forums (we don't need it, for example). Maybe make the integration optional via the settings and save the page processing time for those not needing the close integration?

On a related note, the fetch_threadinfo_query plugin unconditionally JOINs two additional VaultWiki tables - is it really always necessary? What are they used for on the non-Wiki showthread pages?

You can select whether to use the BBCodes or not that VW installs. The option is in the post management before you post a post.

My point is that I want that section gone altogether from the post compose page _in the regular forums_, along with the associated overhead of executing VaultWiki's code. I want VaultWiki to be confined in its forums, and not interfere with the regular forums where it wouldn't be used for us.

Case in point: the PHP execution time of showthread.php _in a regular forum_ with VaultWiki product disabled and enabled (reloaded a dozen of times to get the lowest number):
VaultWiki disabled: 0.12894368171692 sec
VaultWiki enabled: 0.14211702346802 sec

The difference is substantial for a page that doesn't (and wouldn't) have any relation to the Wiki. Also, you can imagine those fractions of second _do_ add up for the large forums.

The added code is not for templates, etc. The added BB-Codes are H and any wiki link BB-Codes (this loads 2 files - 1 for the functions, and 1 for the plugins that add them). About 3 or 4 more files would only be loaded should you opt to use templates, etc.

I believe the forumdisplay plugins are also loaded on all showthread pages, and this needs to be revisited.

I expect that the most overhead comes from the first 2 files that are loaded on every page - the file that initializes the wiki object, and the file that contains the template cache, navbar, and other basic integrations. But these are not things you want to eliminate.

The forumdisplay page also loads plugins that fix the forumbits and threadbits in wiki forums. This is loaded on every forumdisplay page because it may have wiki sub-forums, and from a coding perspective (and factoring memory for non-forumdisplay pages) it was more efficient to not process every combination before loading the file.

While it may not be possible (or reasonable) to reduce the file-loaded count, it's possible that the footprint of each of these files can be reduced by simply separating them into more files that then only load each other as needed. This is something we have planned to do before gold, and one of the reasons we changed the directory structure around.

Quote:

---

Originally Posted by pegasus

The added code is not for templates, etc. The added BB-Codes are H and any wiki link BB-Codes (this loads 2 files - 1 for the functions, and 1 for the plugins that add them). About 3 or 4 more files would only be loaded should you opt to use templates, etc.

I believe the forumdisplay plugins are also loaded on all showthread pages, and this needs to be revisited.

I expect that the most overhead comes from the first 2 files that are loaded on every page - the file that initializes the wiki object, and the file that contains the template cache, navbar, and other basic integrations. But these are not things you want to eliminate.

---

But that's exactly what I want to do :) I don't need navbar changes or any Wiki templates to load in the regular forums. Why would they need to be loaded if they aren't going to be used?

What about the below, why are these 2 tables needed on overy showthread page?

Quote:

---

On a related note, the fetch_threadinfo_query plugin unconditionally JOINs two additional VaultWiki tables - is it really always necessary? What are they used for on the non-Wiki showthread pages?

---

Okay what I am trying to do is break down the wiki class into smaller files, some simply for better organization. While this will mean that more files need to be loaded on pages that reference the wiki, it will also allow for much of the memory consumption to be eliminated when the navbar link is disabled -

It is mainly this which requires wiki info on every page (it needs the wiki namespace cache, URL format, permissions), and disabling it would reduce the wiki object to a relatively empty shell (that extends only as other wiki functions are called). This would still load 2 files on every page, the (significantly reduced) wiki object, and the basic page-irrelevant plugins like cache_templates, parse_templates, global_complete. Each plugin will be significantly reduced so that much of their code is only loaded into memory if the wiki object has been extended in the appropriate way.

My work on this so far has already saved several hundred KB on non-wiki pages...

Thank you for the update, looking forward to seeing the results of your work.

Okay, I'm almost finished with these changes. I've done most comparisons on forum home, which is probably the most trafficked, non-wiki page on any site.:

• Memory consumption was reduced by about 400KB.
• Page generation time, hard to say because it's a very variable figure, possibly -0.01
• Number of VaultWiki files loaded increased (to be expected, since larger files were broken into smaller files)
• VaultWiki files were loaded much later in the PHP process

However, all my tests were done on a board that utilizes most of VaultWiki's integration figures. I expect that the improvement will be much greater for sites that have:

• the Wiki navbar item disabled (this one is key, since it appears on most pages and needs 3 bulky libraries - field, url, and encode)
• namespaces don't appear in the forum bits
• header namespace not configured
• no domain manager settings
• auto-links disabled

I know this is a very rigorous suggestion, but in regard to separation of the code: wouldn't it make sense to make a wiki content type at some point?

Not until it makes sense to do so. Currently the vBulletin CMS even uses the post table to save data (all the comments are actually posts). For now, it doesn't really look like much efficiency will be gained by moving the wiki to a different content type - except in cases where boards plan on having millions of articles. There are still a number of other changes needed to allow VaultWiki content to scale to that level smoothly (in terms of books and metadata caching), which we plan to roll out early in 3.x. The largest VaultWiki implementation right now I believe only has 10s of thousands of articles, so unless Wikipedia itself wanted to import, we have a little more time to figure this out.

However, yes, moving to a separate content type is a very rigorous suggestion because we need to:

• Rewrite the entire mod (the suggestions earlier in this thread already required a rewrite to implement)
• Create completely separate inline moderation, instead of using vBulletin's thread moderation.
• Complicate the process of moving threads in/out of the wiki.
• Still support vBulletin 3 which is over 50% of the market and doesn't support content types. Figuring out a functional degradation method would require a lot more planning.
• Have a stable enough product that we can dedicate a month or two to work on this without worrying about releasing maintenance updates.

Please make this suggestion in the Bugs, Requests, etc area so we can try to get it done by 3.1.0. I don't see it being implemented before the fall.

I think the wiki aesthetics and front end operation as far as 'Members can see'..... should be totally separate from the vbulletin forum looks....... and not use words like article, pages, forum... everything in the wiki should refer to wiki, example: Create Article, should be Create Wiki... Search Forum should be Search Wiki.... Yes, I know it all can be changed via phases and its a big job, then comes a new upgrade which are frequent and it has to all be redone.

And with wiki 'forums' hidden (should be called Wiki Main or something other than forum), no part of the wiki should look like the vbulletin forum or at the very least no member should have access to it......... for example the Image link page should never direct to here
http://tvlampforum.com/wiki-images/ members should never be able to see or get to this page

It should instead always direct to here http://tvlampforum.com/showwiki.php?...cial:Imagelist

So members don't get confused and think the wiki is a forum.

Can I redirect my links like that???

Massive rephrasing, redesign of the forum integration is planned per this task: http://www.vaultwiki.org/issues/1650/

As an example, edit your Wiki Images forum in your Forum Manager. For the setting "Forum Link", enter the URL to the Special:Imagelist page.

This is great news.

Correct me please...... but would it make sense that VaultWiki is a standalone product with only vbulletin login and permissions being mingled (if needed) and having its own wiki database? Wouldn't it run quicker and make it easier to setup?

It doesn't even have to commingle with Social Groups.

This way it can also be sold as a standalone = more revenue. I don't even know if this is possible.

Bugs don't matter when you have EXCELLENT support from the author like VaultWiki has, I also want to comment Murat too from VbTube... these 2 are the best in support. Love ya Teddy!

The whole point of VaultWiki is that it isn't a standalone product that has simply been bridged. The main reason for the upcoming rewrite is not to make it less dependent on vBulletin, but just to make data management easier from the server's standpoint (and easier to setup). We will not be removing any features or current integrations.

I really like that you are going to rewrite Vaultwiki into a CMS content type.

One thing to take into account is that vb4's CMS unfortunately is not yet usable for medium to large sites, due to its amount of bugs and performance problems. I would expect this to be resolved around vb4.1

So unless someone provides instructions how to fix up the vb4 CMS performance (like DP did for vb4 forum), medium to big boards, will have to wait for vb 4.1

I like this idea too only my concern is it remains looking the wiki and never looks like a vbforum or any vbpage or have any vbulletin verbiage (it should all be wiki this and wiki that)... and remain only as a wiki should look. It's wonderful to watch over the years how this product has evolved and great to have dedicated coder like Ted.

I am ready to buy another brand-free wiki for my business site... next version and I will buy it... too many bugs in current version. I am patient :)

Quote:

---

Originally Posted by Alfa1

One thing to take into account is that vb4's CMS unfortunately is not yet usable for medium to large sites, due to its amount of bugs and performance problems.

---

vBulletin has misnamed its content-type system. You do not need to have the CMS installed or enabled in order to use content-types (forums, posts, group-discussions, blogs, etc are all content-types and don't rely on the CMS).

Quote:

---

Originally Posted by Jella

my concern is it remains looking the wiki and never looks like a vbforum or any vbpage or have any vbulletin verbiage (it should all be wiki this and wiki that)... and remain only as a wiki should look.

I am ready to buy another brand-free wiki for my business site... next version and I will buy it... too many bugs in current version.

---

With the content-type rewrite we will be moving away more completely from verbiage like "forum" since we won't be relying on vBulletin features that might cause user confusion.

Yesterday we released 3.0.1, which fixes all the bugs which have been reported and solved since gold. In terms of stability, typically beta releases fixed about 80 known bugs, this one only fixed roughly 40. Most of the remaining items in the tracker are feature requests.

Excellent, my new orders coming later today and I will upgrade my 3 other sites with the new version when I get some time.

This is what support is all about, a dedicated coder like Peg. Thank you.