How can I find out what templates are used to render a page?

[briangreul]

When doing minor modifications it's often nice to know what templates are involved. It's also nice to know what templates are used to build a page for debugging purposes.

Is there a way to find out what templates are being used on a given page?

I have a debugging issue right now where I broke something minor and it's killing inline moderation. I've looked at the 3 or 4 templates, but I don't see anything evil. The pages all work fine, it's only when I try to moderate them.

Generating a list of templates to evaluate would help me to narrow my search.

I've also done a lot of trial and error when trying to change something. I hate hunting for the offending template that needs modification.

[Lynne]

Turn on debug mode and all the templates are listed on the bottom of the page. Enter this in the config.php file:
$config['Misc']['debug'] = true;

This shows for everyone, so do it on your test site.

[briangreul]

Turn on debug mode and all the templates are listed on the bottom of the page. Enter this in the config.php file:
$config['Misc']['debug'] = true;

This shows for everyone, so do it on your test site.

THANK YOU! I've been struggling with this for a while. You have no idea how much hassle that will remove.

We don't get a large amount of traffic, so I can turn it on, see what I need to and turn it off without it being a big deal. If a couple of users see it, no big deal.

It's a shame that the vbulletin.com forums weren't as helpful. I got a very nasty "find it yourself" response over there.

[Lynne]

Sometimes you run into a user that isn't helpful, but I'd give vb.com another chance because they really do have an outstanding group of support guys.


If you have a static IP, you can set debug to be on only for you:
if ($_SERVER["REMOTE_ADDR"] == "xxx.xxx.xxx.xxx") {
// enable debug mode for only my IP address
$config['Misc']['debug'] = true;
}
Replace xxx.xxx.xxx.xxx with your IP. You cannot, however, set it to only show for userid 1, or whatever, because your userid is not known at the time the config.php file comes into play in the page.

[jchamber2010]

This might or might not work, but add that line to another file like the bottom of global.php, then you could use


if ($vbulletin->userinfo['userid'] == 1) {
// enable debug mode for only my USERID
$config['Misc']['debug'] = true;
}

Modifying vBulletin core files as described in this post is extremely in advisable.
Modifying core vBulletin files will result in loss of official support from vBulletin.com.
Use the contents of this post at your own risk!

[Dismounted]

This might or might not work
You will lose the "explain" functionality if debug mode is set late in the execution.

[briangreul]

I finally had some time to do some digging. I still have an issue.

I'm not sure why inline moderation is broken, but it is. I can't move, merge or otherwise affect posts from the thread view. I also have difficulty with inline moderation from the forum view where I can see multiple threads. The moderation tool at the bottom of the page is what is affected. It appears to submit the affected posts to inlinemod.php which blows up on line 3869.

I'm not necessarily wanting someone to solve my problem for me. I am however interested in suggestions on how to troubleshoot this or where to look for the problem.

I have a number of moderations to my templates. I have gone through and one by one disabled them, tested, and re-enabled them with no success.

I have a number of mods installed most of which are supported and I don't believe any of them are the culprit. They are mostly things like twitter hooks.

I'm reasonably confident that this isn't related to my mods. Most of my mods revolved around masking user info from guest users. I just wish I had a more meaningful error message then :
Parse error: syntax error, unexpected $end, expecting T_VARIABLE or '$' in /home/brianpz/public_html/forums/inlinemod.php on line 3869

That doesn't exactly tell me very much... other then looking at line 3869:

$edit['parseurl'] = ($vbulletin->GPC['parseurl'] AND $vbulletin->forumcache["$destpost[forumid]"]['allowbbcode']);
$edit['disablesmilies'] =& $vbulletin->GPC['disablesmilies'];
$edit['enablesmilies'] = $edit['allowsmilie'] = ($edit['disablesmilies']) ? 0 : 1;
$edit['reason'] = fetch_censored_text($vbulletin->GPC['reason']);
$edit['title'] = $vbulletin->GPC['title'];

// Update First Post
3869---> $postman =& datamanager_init('Post', $vbulletin, ERRTYPE_ARRAY, 'threadpost');
$postman->set_existing($destpost);
$postman->set_info('parseurl', $edit['parseurl']);
$postman->set('pagetext', $edit['message']);
$postman->set('userid', $userid, true, false); // Bypass verify

Any suggestions on how I should troubleshoot this?

So far I have:
- checked that template modifications weren't the obvious cause of the issue.
- turned on template tracing to get an idea what templates are involved.
- looked at the offending PHP code and line 3869 and took a glance at the preceding code... although I'm not really a PHP coder. I am very experienced in ASP/vbscript so this isn't that strange.

It seems like the next solution would be to try and backtrack in the code and figure out how it gets to 3869 and check for broken items.

It seems like the basic logic is that checking off the checkboxes on the thread selects the post ID and then sends these to inlinemod.php. From there inlinemod.php checks some security and performs functions. Somewhere along the way it's complaining about the data on page 3869.

I am using the legacy postbits... so there could be a conflict between them and the inlinemod.php.

[Lynne]

Have you tried using a totally default style and seeing if things work then?

Create a new style with no parent:

Styles & Templates > Style Manager > Add New Style
Parent Style: No Parent Style
Title: Default vBulletin
Allow User Selection: Yes
Save

Then browse the site using that totally default vbulletin style - do you still have the same problem?