Printable View
Quick question -- does the TABLE bbcode functionality included in VaultWiki conflict with the BB Code [table] add-on for vBulletin? If so, what is the recommended upgrade/transition path away from this highly popular add-on? (I notice this issue, but I'm not familiar with a comparison of the VaultWiki bbcode versus the vB Germany table bbcode, so I'm not sure which one would ultimately be preferable.)
Thanks for your thoughts!
The wiki TABLE BB-Code and the StGaensler TABLE BB-Code (the one in your link, aka the vB Germany TABLE BB-Code) use different syntax. The wiki TABLE BB-Code uses internal syntax like that of MediaWiki's Table Syntax (the opening and closing tags are obviously different).
Depending on which one you want to use, you should modify the bbcode_create Execute Order (the later one will override the earlier one).
There is no automatic converter for the TABLE codes (except NuWiki's to VaultWiki's). If you choose to use VaultWiki's, you'll need to either develop a conversion plugin, or make the changes manual.
Is there a way to turn-off the VaultWiki TABLE? NuWiki had an option where you could check off which included bbcodes would be used/parsed. It'd be great if I could elect to escape out of certain bbcodes and save my forum the performance hit.
I assume the easiest way is simply not to use the code... and I think from memory that VW adjusts the BBCode to change the [table] to become it's default code, though I could be wrong.
If it does, adjust (through the BBCode Manager) the BB Code Tag Name to something different, keeping the [table] tag for the other version you use. Then it should only run through the old system, leaving VWs alone.
However, I can't be certain this will solve your problem, as I've not tried this personally. I'd test it on a test board/install first, unless Pegasus can confirm sometime soon if this is the solution... :)
There is currently no way to "turn off" the TABLE BB-Code. This is a change we're planning for the parser rewrite in RC 2: http://www.vaultwiki.org/issues/1275/
In the mean time, you can modify the file vault/special_plugins_bbcode.php and remove the definition:
Code:if (empty($parser->tag_list['no_option']['table']['callback']))
{
// [TABLE]
$parser->tag_list['no_option']['table'] = array(
'callback' => 'handle_external',
'external_callback' => 'special_bbcode_table',
'strip_empty' => true,
'strip_space_after' => 1
);
}
Thanks, pegasus. Alternatively, let's say I wanted to offer my users multiple ways of building tables. Is there a way that I could change the VaultWiki TABLE bbcode to something else (like maybe [GRID]?). And, from a performance stand-point, is there a preferred path to take with regards to these BBcodes (that is, does having multiple BBcodes, even if one is rarely used, cause a performance hit)?
It really should not affect performance to have rarely or unused BB-Codes. Neither vBulletin nor VaultWiki search for BB-Code usage on a tag basis, but rather the reverse. It just stores them in a registry and checks what it thinks might be BB-Code against the registry.
If you wanted to rename the TABLE BB-Code, you'd have to create your own bbcode_create plugin that adds [GRID] with the same definition I instructed you to remove above.
Could you possibly give me an example of how this would be done? Let's say I wanted the TABLE bbcode that shipped with VaultWiki to instead be a GRID bbcode. What changes would I have to make to an out-of-the-box VaultWiki installation?Quote:
Originally Posted by pegasus
Thanks for indulging me. I know that designers will prefer the TABLE bbcode that you submitted, but newbies will likely want a more simplified table schema more akin to what vBGermany offered.
Add the following plugin for bbcode_create, set the product to vBulletin.
Use the following code:
Code:$this->tag_list['no_option']['grid'] = array(
'callback' => 'handle_external',
'external_callback' => 'special_bbcode_table',
'strip_empty' => true,
'strip_space_after' => 1
);
Thanks, pegasus! Worked perfectly. :)
In RC2, when you give us the option to turn off the TABLE bbcode for VaultWiki (ostensibly in favor of the vBGermany TABLE bbcode that we are otherwise using), will my bbcode_create plugin for the GRID bbcode still work?
Yes it should. The switches will only affect the definition of the BB-Code. In your case, you have added your own definition without an option-check.
Thanks. I have another weird issue.
Ever since disabling the VaultWiki TABLE bbcode, per your instructions on the first page of this thread, my vBGermany Table bbcode is no longer functioning properly in VaultWiki (though, to be fair, I'm not sure it was ever functioning properly in VaultWiki). Do you have any insights or perspectives as to what might be causing this issue? The major defect in VaultWiki seems to be that the vBGermany TABLE bbcode enters all of its content in a single row, regardless of the carriage-returns to indicate separate rows.
The vBGermany TABLE bbcode works fine on the rest of the site, however; as does the GRID bbcode, universally (both on VaultWiki and non-Wiki forums/posts). Thoughts?
Line break behavior is not consistent across the wiki and regular parsers. Until the next build (at which time you'll want to reverse the following change), you should make the following change: http://www.vaultwiki.org/issues/350/#note1899
Thanks so much!Quote:
Originally Posted by pegasus
** Edit ** nm, I figured out how to turn off the wiki table in the settings.
I'm having this same problem. Commenting out the suggested code doesn't appear to affect it.
Sorry to drag up this old thread, Pegasus, but I figured this might be the easiest way to raise an issue we're having. Back in Jan/Feb, I upgraded VaultWiki to 3.0.16. Since that upgrade, threads that have any post with the GRID bbcode experience a 500 error when a user clicks the "Reply" button -- though Quick Replies work just fine. Any thoughts as to what might be causing this?
A few notes:
- Still using the GRID bbcode plugin you defined on page 1 (execution: 5 -- though changing this to values ranging from 1 to 10 causes no difference).
- Still using TABLE bbcode from vBGermany.
- GRIDs and TABLEs are both rendering just fine in posts and the Wiki; it's only when clicking "Reply" (and having the vB parser run through posts with GRIDs) that causes the 500.
Thanks so much for your help!
Note: Running on vBulletin 3.8.7 PL2.
Please check your logs for a better description of the error. 500 can be anything, especially when servers have error reporting to the client disabled.
Is it all replies or just wiki comments?
Does the submission seem to hang for a while before returning 500? If so, there may be an infinite loop/recursion somewhere.
Hi Pegasus,Quote:
Originally Posted by pegasus
Thanks so much for replying so quickly. Unfortunately, as I'm on the Rackspace Cloud, I don't exactly have access to traditional server logs for Error 500. :/
1. This is with all instances of newreply.php - wiki replies and forum post replies. As long as there is the Wiki Table (in this case, GRID) bbcode occurring, the newreply.php returns an Error 500.
2. The submission does not hang; it's pretty much instant.
Any thoughts on what I could try to debug a bit?
Thanks!
In this case what we would do is go line-by-line from the end of the postreply action and add "die('ok');" until you don't get server 500 anymore. Probably good to have a test thread for this:
Using this you should be able to isolate what line of code causes the 500 error.Code:if ($vbulletin->userinfo['userid'] == MY_USER_ID)
{
// replace MY_USER_ID with your numeric ID
// this way only you see this hackish debug
die('before server 500');
}
It's a pain, I know. But without randomly changing things, that's really all you can do when you get an error that doesn't generate log items.