TABLE bbcode

[Kaelon]

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!

[Kaelon]

Note: Running on vBulletin 3.8.7 PL2.

[pegasus]

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.

[Kaelon]

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,

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!

[pegasus]

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:

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');
}

Using this you should be able to isolate what line of code causes the 500 error.

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.