Before I "properly' learned how to preregister variables and custom templates in a default vBulletin template, I had no clue how to use all the custom code I had developed for my site on the standard pages my members would use. I figured out a quick and handy workaround to registering a new template just for a quick variable to display something on a standard page, or to use for a if condition.
First off: Create a plugin in the appropriate place. Example: I have custom forms for my members to use in appropriate threads that are a little different than simply replying, so I need to keep the new reply button as is, and I add an additional button next to it. In this case I used the postbit_display_complete hook (also added an if($post['parentid'] == 0) condition since I used a query in the plugin and didn't want the query called during EVERY post in that thread, and for some reason I could never get it to work with a showthread hook).
Now, all variables you decide this plugin will be putting on the vBulletin page must get on somehow, and it had to be a registered variable or template preregistered to be able to be accessible to the template, this hasn't changed. So how do you get around this? The trick: use a variable ALREADY registered!! You have a few available to you almost everywhere anyways: $post, $thread, and $userinfo, to name a few. Simply add the important information to a array key or an array merge as we will be doing below, and you can use like any other variable in that array!
Heres an example of code that could work for you:
Plugin: postbit_display_complete hook
PHP Code:
if($post['parentid'] == 0 && THIS_SCRIPT == 'showthread') //Use if conditions and don't waste memory by calling the plugin code and/or queries when not on a page that needs it
{
$threadtid = $vbulletin->input->clean_gpc('g', 'threadid', TYPE_UINT); // I'm sure $thread['threadid'] etc works without a new variable, just I'm a quirky coder about using arrays in query commands, sue me :p
$getinfo = $vbulletin->db->query_read("SELECT * FROM exampletable WHERE threadid = '$threadtid LIMIT 1'");
$info = $vbulletin->db->fetch_array($getinfo);
$thread = array_merge($thread, $info);
}
Now my particular table saves info including a threadid for each entry, hence why I used that as the WHERE condition, that isn't necessary, just as an example. As you can see though, we now have ALL information from the row in that table that has that threadid. I also have a 1 row limit on that condition to avoid a possible issue, but more rows would be fine provided you used a while loop to assign the information before merging your information. This also MUST be an array you use, so either use the query array, or cast the variable into an array, etc.
To use in a template now:
Template: SHOWTHREAD
HTML Code:
<div id="above_postlist" class="above_postlist"><vb:if condition="$show['largereplybutton']"><a href="newreply.php?{vb:raw session.sessionurl}p={vb:raw LASTPOSTID}&noquote=1"
class="newcontent_textcontrol" id="newreplylink_top"><vb:if condition="$show['closethread']"><span>+</span> {vb:rawphrase reply_to_thread}<vb:else />{vb:rawphrase closed_thread}</vb:if></a><img style="display:none" id="progress_newreplylink_top" src="{vb:stylevar imgdir_misc}/progress.gif" alt="" /></vb:if><!-- Above code is in the showthread template already, here is the custom code --><vb:if condition="$thread['examplerow1']"><a href="example.php?{vb:raw session.sessionurl}info={vb:raw thread.examplerow2}"
class="newcontent_textcontrol" id="infolink_top">{vb:raw thread.examplerow3}</a></vb:if>
It's that simple! As you can see I have used both in a vb:if condition AND as a vb:raw array key, so it can be useful either way!
Hopefully this may help some of you have an easier way to upgrade from VB3, or use in a quick and dirty edit if coding design/portability does not concern you.
It is bad practice to piggyback your stuff on existing variables. Learn how to properly register them (it's not that hard) instead of starting to do it the wrong way.
BTW, $thread of $post-variables are by no means available almost everywhere.
I'm totally in agreement with that
That was why i said 1. It was before I learned the proper way, and 2. only real usage I can see is a quick and dirty edit where there is no concern about portability or proper code structure. I definitely wouldn't recommend it as a long term fix for an important page of your site or a bigger hack/project.
As far as the arrays chosen, I only used those as an example, $user and $phrase would be a little more broad if you want more availability
07-24-2010, 10:00 PM
07-30-2010, 07:46 PM
